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ABSTRACT 


In this thesis we discuss the design issues of a styl- 
ized natural language syntax for Omega, an object-oriented 
programming language tuilt upon rule-based pattern matching. 
Emphasis is placed cn simplicity and flexibility in the 
design. The feasibility of the proposed grammar (Omega-1.5) 
is evaluated by develcping a prototype translator to trans- 
late the Omega-1.5 grammar into the predicate logic style of 
Cmega-1. Sample applications are provided to examine the 
features of the grammar and to explore possible application 
areas. Limitations in the design are analyzed and potential 
amelieriations are suggested. We conclude with a general 


assessment of the overall Omega system. 
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I. INTRODUCTION 
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A. | BACKCROUND 


The evolving complexity of modern computer applications 
is leading to basic changes in the nature of programming. 
There is a growing awareness that conventional programming 
languages are not adequate for building computer systems. 
Frogrammers are demanding increasingly sophisticated tocis 
for understanding and manipulating intricate, ill-defined 
problem domains. Successive conventional languages have had 
little success in prcviding additional tools to help the 
proyrammer combat tke complexity barriers. Although the 
languages are getting larger, they are not getting stronger. 
As John Backus stated, "Inherent defects at the most rasic 
level cause them to be fat and weak....'" (Ref. 1: p. 613] 

Backus further stated that a major limitation of the 
conventicnal languages was the "word-at-a-tine" programming 
style. An example of this style is evidenced in the array 
construct [Ref. 2: E. 404}. Arrays are processed by 
performing an action on each individual element, with all of 
the indexing and loop control that this action requires. 
Thus, the programmer is occupied with minute implementation 
details rather than ccnfining his thinking to the larger 
concertual units of the task. 

Programmers must shift their focus away from the 
detailed specifications of algorithms. The basic use of 
programming systems is not in developing sequences of 
instructions for acccmplishing tasks, but in expressing and 
contrelling descripticns of computational processes [Ref. 3: 
peol3 is High level languages were initially developed to 


free the programmer from the turdensome details of machine 


code. Languages with even higher levels of abstractions are 
now required to rescue the programmer .from inundation -by 
unnecessary implementation-related details. Increased 
semantic power from the use of abstraction cannot be 
achieved, however, at the expense of architectural effec- 
tiveness. The conventional notion of programming languages 
needs to Le reevaluated. 

Alternatives to conventional languages have existed for 
quite some time. An early example is LISP. The original 
LISP system was characterized by the application of pure 
functions to list structures. This application of a func- 
tion tc its argument is indicative of applicative program- 
ming. Other alternatives tc conventional languages are 
cbject-oriented programming and logic programming. One 
language framework that combines the features of the appli- 
cative, object-oriented, and logic programming categories is 
a language called Omega [Ref. 4]. This thesis shall focus 


on the features of the Omega framework. 


B. THE CMEGA LANGUAGE 


in order to understand the foundations of Omega, it is 
necessary to analyze the three categories of alternative 
languages mentioned ir section A (see sections C, D, and £). 
The influences upon Cmega from languages in these categcries 
will become quite ckEvious as the features of Omega are 
explored. First, however, a general overview of Omega is in 
order. The backbone of Omega is the concept of object- 
oriented programming. A pioneer language in the object- 
oriented field was Simula (Ref. 5). As the name suggests, 
Simula views all programming as simulation. This concept is 
fundamental to Omega's view of objects. 

One unique feature of Omega is the provision for four 


alternative syntactic forms which represent the same 


language. The first form (Omega-1) uses a predicate logic 
style and is the easiest to parse. The second and third 
forms use syntactic "tricks" to approach a pseudo-natural 
language format. This style is much easier for a naive 
computer user to read. Omega-4 further addresses the read- 
ability issue by using a two-dimensional format built upon 
the use of a form. The notion of multiple syntaxes creates 
a rich environment that supports many levels cf user 


sophistication. 


C. OBJECT-ORIENTED LANGUAGES 


The object-oriented paradigm of Simula was smoothed and 
cemented in the Smalitalk language (Ref. 6). It was the 
Smalltalk programming system that actually produced the term 
"object-oriented." Although there is some evidence of LISP 
in Smalltalk, the class notion from Simula has become domi- 
nant in the design. The class notion is the basic struc- 
tural unit, with instances of classes, or objects, being the 
concrete units which comprise the Smalltalk systen. 

There are many advantages in the object-criented 
approach. The simulation paradigm of objects is well suited 
to modeling real-world objects. Another advantage is the 
concept cf state--objects hold the state of a computaticn. 
Additionaliy, an object orientation easily supports such 


Concepts as abstract data types, information hiding, and 


nodularization. A more intuitive appeal of objects is 
Simply a sense of uniformity. No object is given any 
special status; there are no "second class citizens." A 


user-defined object is an object just like a system-defined 


object. 
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D.  APPLICATIVE LANGUAGES 


Applicative programming extends the model of mathematics 
to the world of computer programming. Applicative languages 
kasically involve the application of functions to their 
arguments. Underneath the various syntactic idiosyncrasies 
of applicative languages is the rigorous structure of the 
lambda calculus. Various syntactical forms are merely 
“Syntactic sugar" [Ref. 7] to heip soften the rigid aprear- 
ance cf the lambda calculus format. Two well known applica- 
tive languages are pure LISP [Ref. 8] and the FP language 
Bnet. 1). 

Applicative programming encourages the use of higher 
levels cf abstraction through the use of functionals. 
Functicnals are mechanisms for modifying the behavior of 
existing programs by combining primitive computational units 
into complex, powerful collections. Specifically, a func- 
tional is a function which receives functions as arguments 
and returns functions as results. 

Ancther advantage of applicative programming is the 
notion of manifest interfaces. That is, the input-output 
connections to a subexpression are distinct and there are no 
hidden interfaces to complicate the semantics of a process. 
A final benefit is parallel evaluation, which is suprorted 
Ly the evaluation crder independence of expressions. 

Applicative language progranning is essentially synony- 
mous with value-oriented programming. Consequently, it is 
subject to the basic characteristics that are associated 
with values. The notions of time and state are lacxing in 
value-criented prograrning. This limits applications where 


temporal relationships are required. 
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E. LCGIC PROGRAMMING AND INFERENCE SYSTEMS 


The development cf Prolog [Ref. 9] in 1970 has made 
logic programming quite popular in recent years. Prolog has 
many applications in the artificial intelligence and infer- 
ential programming fields. It has been selected by the 
Japanese as the core language for their much-touted Fifth 
Generation Project [Ref. 10]. Prolog uses rule-tased 
pattern matching as the basis for computation. A Prolog 
program consists of clauses, where each clause is either a 
fact or a rule about how the solution may be "inferred" froa 
the datakase of facts. This is the first step toward logic 
programming. In conventional languages, different forual- 
isms are used for expressing programs, databases, speciíica- 
tions, and constraints. Logic can be used to provide a 
Single uniform language for all of these tasks. 

Inference systems are usually associated with artificial 
intelligence applications. Rule-based paradigms have been 
used for problem-solving production systems and even for 
knowledge representation. A popular application has been in 
expert systems. For example, MYCIN [Ref. 11] and INTERNIST 


TRef. 12] are two well-known systems in the medical field. 


XCON [Ref. 13], another exarple, is a system used at 
Carnegie-Mellon University for configuring computer 
components. 


F. DEVELOPING AN ALTERNATIVE SYNTAX 


The objective of this thesis is to develop and implement 
a natural language style syntax for the Omega language. 
Concerts from the  Orega-2 and Omega-3 syntaxes will be 
synthesized into the development of an Omega-1.5 grammar. 
The ideal engineering solution for  Omega-1.5 is to create a 
highly readable syntax at a minimal cost. Fliexibility, as 


well as simplicity, is key to the design. 
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The feasibility cf the 1.5 grammar was demonstrated by 
constructing a translator to translate programs written-in 
the 1.5 grammar into the predicate logic syntax of Omega-1. 
The development of the translator was considered to bea 
learning process in that language features of the 1.5 
grammar were studied and changed as necessary throughout the 
programming process. Translator features such as efficient 
code generation and elaborate error checking were considered 
to be of secondary importance. 

Another objective of the thesis was to develop exanrle 
applications in the 1.5 grammar and to run them first on the 
translator and then to run the translation on the McArthur 
interpreter [Ref. 14}. This approach permits an informal 
evaluation of the naturalized syntax. Additionally, TE 
provides a beneficial vehicle for evaluating potential 
application areas for the Omega-1.5 grammar. 

The Omega language is still in the experimental stages. 
Therefore, some attention has been placed on the general 
features of the language. Possible future design modifica- 
tions are suggested and subjectiveiy evaluated. Deviations 
from language features of the McArthur prototype are aiso 
noted. A final task is an introspective evaluation of Omega 


as a general-purpose programming language. 


II. THF OMEGA-1 IMPLEMENTATION 


A. PREFACE 


General features of the Omega-1 syntax will be discussed 
in this chapter. The Omega concept was originally developed 
Ly Bruce MacLennan. A description of the language anda 
formal syntax for these constructs is presented in [Ref. 4). 
These constructs were implemented by McArthur [Ref. 14] 
through a prototype interpreter. Some semantic and 
syntactic differences do exist between the original theory 
of the language and the actual implementation. A listing of 
these differences can be found in [Ref. 15]. The following 
summary will discuss Omega as amended by the prototype 


implementation. 


Be OBJECTS AND VALUES 


The tasic elements in Omega are values and objects. A 
detailed discussion of the two is in [Ref. 16]. Sea cris 
objects are entities that have a unique identity and possess 


the fcllowing characteristics: 
e objects exist in time and can change in time. 
e objects may be created and destroyed. 
e objects are unique, but ray be shared. 
e cbjects have a state (the sum of the relationships with 


all other objects in the system). 


Values are mathematical entities and thus have the following 


Characteristics: 
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e values exist independently of time. 
e values are not subject to change. 


e values cannot be created or destroyed. 


Typical values in Omega include character strings, integers, 
and lists. A list is a collection of expressions enclosed 


ty brackets. Two exarples of lists are: 


(red white, blue] 
[1,2,11,2]] 


C. RELATIONS 


Relations are the "glue" which connect the components ia 
Cmega. In mathematical terms, R is a relation cn then 
sets, S¡1S7...-S, 1 if R is a subset of the cartesian product 
S X SX... 5. Informally, a relation isa set of 
tuples, which are simply ordered collections of objects and 
values. Unlike relational database models, named attritutes 
are nct used to describe tuples. Instead, elements of 
tuples can be described by value, bv relative position, and 
ty pattern-matching. Tuples in a relation are unigue. 
Additionally, there is no order among tne tuples in a 
relation. 

Relaticns are described either through pattern-matching 


or by name. A possitle relaticn in Omega is: 


perform(compilers,{ scanning, parsing, 


COde generation] 


This relation is named by the identifier perform. pt 
consists of a binary tuple, <compiler,(scanning,  rarsing, 
code generation]», that contains the object compiler anda 
list cf the objects scanning, parsing, and code generation. 


It shculd be noted that relations (and objects) in Omega 


ta 


must Le defined prior to their use. Definitions are estab- 
lished through procedure calls (section F). 

Relations help determine the state of an object. An 
objects's state is defined by its associations with cther 
values and objects in each of the relations in which it is a 
member. Relations are also objects, although they differ in 
that they have the inherent value of their tuples. As 
objects, relations nay participate in other relations as a 


member of a tuple. 


D. THE PRODUCTION RULE SYSTEM 


The behavior of the entities in Omega is descrited 
through pattern-directed production rules. Through these 
rules, state transitions in the system can be described. 


Rules are written as implicaticns of tne forn: 
if <premise> -> <conclusion> 


The premise consists of one or more boolean conditions 
pertaining to the state of the system. The conclusion 
defines actions to be taken whenever the conditions of the 
premise are true. 

Inguiries and constraints are two or the rasic 
constructs in the premise condition. Inquiries are 


expressed as: 
i£ P(X; Y; RR 


Here we are testing to see if there exists (existential 
quantification) a tuple <x,y,z> in relation P. The meaning 
of the premise depends upon the bindings of x, y, and Z. If 
we assume that these are unbound variables, then P(x,y,z) 
wiil match any ternary tuple in relation P. The match will 
result in the binding of the tuple's components to the vari- 


ables X, Y, and Z. 


16 


A more complex inquiry might be: 
Ti MM 2), OIE. 09) => >-. 


The ccmma between the two conditions denotes the logical 
conjunction of the twc conditions in the inguiry. Thus in 
order for the premise to be true, the relations P and Q must 
each have a triple such that the second component of each 
triple is the same. When this condition occurs, the rule is 
Saidi to “fire." 

The absence of a condition can also be tested. This has 


the fern: 
SERN 2) = a a a 


Here the premise would be true if there were no ternary 
tuples in relation P. The interpretation of the absence or 
a tuple as the negation of its presence is dependent uron 
the assumptions of the programmer. Absence and negaticn are 
not necessarily synonymous. 

At this point, the binding of free variables should be 
discussed. Bindings cf free variables remain in effect only 
for the duration of the rule. In other words, the score of 


a free variable within a rule is confined to that rule. 


Free variables are nct bound in a test for absence. QUIS 
tne variables in the implication hP(x,y,Z) —> ... remain 
unbound. 

Constraints may also be used in a premise. Our exanple 


could te written: 
TCR y Z); x «€ 8 -» ... 


where x < 8 is a constraint. Constraints may be any tociean 
expression. 

The second part of the rule is the  conclusicn. 
Conclusicn segments cf an implication may be used to alter 


the state of the system. Consider the following: 
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if E(x,y,Z) -> R(x,y) 


If through pattern-matching, the rule fires (the premise 
becomes true), an assertion, R(x,y), is established where 
the tuple <x,y> is added to the relation R. Remember the 
tindings of x and y in relaticn R will be the "same as the 
bindings of x and y in relation P. 

The use of deletion in the conclusion segment is shown 


aos 
if Pix,Y,2) => F(X.) ltda) 


This will result in the removal of the tuple  (tnat became 
bound to x, y, and z) from relation P. This is quite ccmmon 
in Omega rules. If one or more conditions in the premise 
are not removed in the conclusion, the conditions that 
precipitated the firing of the rule would remain in effect. 
Thus, the rule would keep on firing. An abbreviated syntax 


can be used to denote the cancel operation: 
if $P (xyz) -> E(X,y) 


where *P(x,y,Z) represents P(xX,Y,Z) in the prenise and 
aP(x,Y,Z) ir the conclusion. 

One other syntactical extension is the use cf else 
before an implication to establish a compound rule. Suppose 


we had the following: 


1£ FF (X,Y), *O0 (mn) > R: 
11 FEA Bee OR (UM 


In this example, we want the second rule to fire cnly when 
tte first one fails. The first rule may never fire, 
however, Since the matching of the tuple <x,y> in the P 
relation will fire the second rule. In this case, the 


example could be written as: 


if *P (x,y), *O(m,n) -> R(m) 
else if *P(x,y) -> R(X). 
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Ihe implication associated with the else statement will only 
be evaluated if the first implication fails. 

A summary of the rule features is presented thrcugh the 
following example: 


if *P(x,y),Q(m,4),-R(s),x > 4 -> 730 (m,4),T (x) 
else if *P(x,y) -> T(y). 


It shculd be noted that although many rules may have their 
[remises satisfied (the rules are "triggered"), cnly one 
rule is executed (fired) at a time. The indivisibility of 


rules can be used to support mutual exclusion of processes. 


E. FUNCTIONS AND OTHER APPLICATIVE FEATURES 


Named functions may be used to calculate components ina 
tuple. A function invocation is used in the conclusicn of 


the fcllcwing rule: 
D Ey, Z) -> c(rest[x]). 


The argument to relation Q is a function (note the use of 
brackets for function calls) which returns a pointer to the 
mae CL a list. In this example, variable x must te tLound 
to a list in the premise condition of the rule. Function 


invocations may also ke used as constraints in a premise: 
EMEXE ya Z), first[x] < 10 -> ... 


In this case, variable x must be bound to a list which has a 
first element less than ten. 
New functions are declared as follows: 
fn number_items [list]: if list = Nil -> 0 


else 1 * number itens[rest[ 1ist]]. 


19 


The bcdy of a functicn is a conditional expression similar 
in form toa rule. There are two qualifications. Ihe 


premise can only be a boolean expression, while the conclu- 


Sion can only be ancther expression. This ensures the 
absence of side effects. Note that the conclusion contains 
a recursive call. There are no iterative constructs in 
Onega. 


Functional bodies clearly display six desirable charac- 
teristics that can be obtained through the use of expres- 
sions. These characteristics include “transparency of 
meaning and purpose, independence of parts, recursive appii- 
cation, narrow interfaces, and manifestness of structure 
[Ref. 17:: p. 16]." 

Applicative expressions can also be used to calculate 
tne value of an argument in a tuple. Consider the 


following: 


if *P(x,7,2), y Zoo bz na —» 
DES 


In this example, infix operators are used to calculate two 
constraints in the premise. One infix operator is also used 
to calculate an argument in the assertion of the tuple 
<x,5+z> for relation C. All variables must be bound prior 


to participating in an applicative expression. 


F. PROCEDURES 


Procedure calls are guite similar to the function invo- 
cations discussed in the previous section. Both processes 
return results which may be used in expressions. The under- 
lying mechanism of a procedure call is quite different, 
however, from that of a functicn. One important difference 
is that side effects are possible in procedure calls. This 
is a result of the use of rules to implement the actions of 
a call; 
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A procedure call involves synchronous communicaticn; 
that is, the sender (cbject or process) that made the asser- 
tion expects a reply before continuing. The sender is 
usually expecting one or more rules to be processed prior to 
receiving a response. Procedure calls are distinguished 
from conventional relations by enclosing the asserted tu;le 


in braces. This is illustrated in the following example: 
if *input(x), state(g) -> push{x,mystack}. 


The relation push is a procedure cali. It will ke trans- 
lated by the system into the assertion push(a,x,mystack). 
The object a isa system-supperted relation that represents 
the sender. The relation a will be used as a mailbox to 
hold the response frcr an active rule that contains the push 


relation. This rule could be written as: 


if *push(a,x,stack), *contents(list,stack) -»? 
a(stack), 


contents í(cons[x,list],stack); 


By convention, a is placed as the leftmost member of the 
tuple <a,x,stack>. With the assertion of a(stack), the 
Sender may obtain the result and continue with the comruta- 
tion. The tuple <a,x,stack> could be compared to the estab- 
lishment of a conventional activation record, while the 
mailrcx a is analogcus to the activation record of tne 
Caller: 

The above example shows that the result of a procedure 
call does not have tc be used in an expression. In tals 
case, the returned value is used only for synchronization. 
Another procedure call which does not use the return value 
is the system-defined display procedure. This procedure 
sends a message to the screen. An example of a call that 


uses the return value would be: 


PERSP (X,y,stack) -> 
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Contents (cons[ pop{stack},x],y) - 


In this case, the result frem popping the stack will be 


appended to a list that is bound to variable x. 


Ge SEQUENTIAL CONTRCL 


Consider the following rule from a solution to the 


Towers of Hanoi problenm: 


if *move (user, 1,<ource peg, destination peg, 
auxiliary peg) 
E 
display ("Move disk 1 from peg "3j, 
display (source _pegj, 
display {" to peg "”}, 
displayn {destination_feg}, 


user (Nil); 


Naturally the programmer would like the message to print in 
order. This will not necessarily occur, however, with the 
current structure of the rule. No order is assumed for 
evaluating the conditions of the premise, and no order is 
assumed for executing statements in the come lusicne 
Further, there is no crder associated with the evaluation of 
multiple production rules. 

A mechanism is therefore needed to give the prograaner 


contrcl over processes which transition through  zultirie 


states. The soluticn is a pair of braces. An open trace 
depicts the beginning of a sequential block, and a closed 
trace terminates the sequential block. The previous rules 


could ke rewritten as: 


if *move (user, 1,<ource peg, destination peg, 
auxiliary, peg 
=> 


display {"Move disk 1 from peg "}; 
display (source. pegj; 
display (" to peg "3; 
displayn (destination peg); 
user (NI1) 
P 


Variables bound in the premise will keep their bindings 
throughout the sequential block. Bindings will also be 
retained in nested blccks. 


H. DIRECTORIES 


It has been previously mentioned that relations and 
objects must be defined prior to their use. These defini- 
tion statements are used to bind a global name to the 
desired object or relation. Global names are ccntroiled 
through directories. 

The original schema for Omega [Ref. 4: pp. 34-35 1 
discussed the use of one public and a number of private 
directories. An obvious use for these directories is to 
enforce information hiding. A private directory can be used 


for access control as follows: 
Define {Private,"Push", Newrel {}}. 


The define procedure call makes an entry into a directory 
partition. The Newrel procedure call returns a new relation 
object which is a unique identifier. The name push is bound 
to the new relation otject in the private directory. 

The creation of a new relation associates full access 
rights (capabilities) with the relation name. The access 
rights are read, add, and delete. It is possibie to 


restrict access rights: 


Define {Public,"Fush",AddCnly{Push}}. 
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The AddOnly call creates a copy of the system identifier 
that has been bound to the private name Push. The copy 
differs in that its rights have been restricted. The new 
identifier is then  rlaced in the public directory where it 
Can be generally accessed in accordance with its restricted 
access rights. 

Public and private directories were not defined in the 
McArthur prototype. A single directory named root was 


implemented as shown in the following definition. 


Define froot,"Push",newrel {}}. 


I. PRODUCTION RULE SYSTEM 


The previous prcduction rules are examples of active 
rules in the Omega system. These rules are normally entered 
into a file using a standard text editor (they can also be 
entered interactively). Active production rules constantly 
moniter the relations in their premises on a test-fire 
kasis. A rule denotation ( << >>) is used to syntactically 
distinguish the production rules from command rules (Section 


J). A pcssible rule definition is: 


Define (root, "SampleRules, 
<< 
if *top itermr(a,stack), contents (list,stack) 
=> a(first! list) 
>>}. 


The rules have been entered ina passive status, basically 
parsed but not evaluated. To make the rules active, the 


procedure Act is used: 
Act {Samplerules}. 


The rules are then elevated to an active test-fire status. 


It is possible under the original Omega design to activate 


and deactivate rules throughout a progran. Rule deactiva- 
tion was not implemented, however,. in the McArthur 


interpreter. 


Je  INTERACTING WITH CHEGA 


A second category of rules is the command rules. These 
rules are used to interact with the system. Unlike produc- 
tion rules (which when activated are constantly evaluated), 
the command rules are cnly evaluated once. The evaluation 
sequence for command rules is test, fire, and fcrget 
[Ref. 14: p. 30]. 

One useful application of command rules is queries. An 
example of a session with Omega that combines the command 


rules with the production rules is presented below: 


Define {root,"Married", newrel {}}. 
Define f{root,"Brcther", newrel {}}. 
Define froot,"Bili",newrel {}}. 
Define [root,"Karen",newoEbjí]]. 
Define [root,''Joe",neworj(íll. 


Define {root,"Jane", newobj {}}. 


Define {root,"Sazplerules", 
SS 
if *Brother (x, Joe) -> Married (x, Xaren) ; 
if *Brother (x,Bill) -> Married (x, Jane); 
>>}. 
Act {Samplerules}. 
The definitions and froduction rules could have been entered 
interactively or froma file. If a file is used, the file 
nust be activated with the procedure Do. 


Suppose the user wanted to establish that Bill was the 
brother of Joe. He would enter  Brother(Bill,Joe). ihe 
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first production rule would fire thus asserting that Bill is 
Married to Karen ( Married(Bill,Karen) ). Next the user 
might enter: 


if Married(Bill,Raren) -> Display ("Yes"). 


Since Married(Bill,Karen) has been asserted, Omega will 


respond with Yes. 
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III. CMEGA-1.5: DESIGN ISSUES 


A. GOALS 


Four different syntactical forms have been suggested for 
the Ozega language [ Ref. 15]. The second and third alterna- 
tive forms suggest a pseudo-natural style that provides a 
greater degree of readability for novice (and experienced) 
users of the language. Readability has long been an issue 
in the development of computer languages. A 1973 memorandun 
ty C. Hoare listed readability as one of the top five ckjec- 
tive criteria for good language design (Ref. 17: p. 6]. The 
goal of the Omega-1.5 granmar was to develop an independent 
design that fulfilled the intent of the Omega-2 and Omega-3 
grammars (primarily Omega-2) and to test the feasibility oz 
implementing such a design.  Inherent in this objective were 


the following design characteristics: 


e Readability. The 1.5 grammar had to offer a notable 
increase in readability over the predicate logic style 


notation of Omega-1. 
"-nasdrcity. 


1. The engineering solution must be Simple and 


practical. 


2. The syntax should have a close correlation tc the 
Omega-1 syntax. The original thought was to have 
an injective mapping (after the removal of the 
noise words) from Omega-1.5 to Omega-1 (a function 


f£:A->B is injective if a<>a't implies f(a)<>f(a"')). 


3. There should also be a close correlation between a 
translated version cf Omega-1.5 program and a 


program written in Omega-1. 
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4. Additional definition statements should be kept to 


a minimum. 


e Flexibility. A programmer should have the capacity to 
write a relaticn in many ways, - depending upon the 
context. The design shculd also be extensible. A 


programmer should be able to augment the given collec- 


tion of noise werds as necessary. 


Upen completion of the design, a translator was built to 
test the design's feasibility. Sample programs were then 
written to evaluate the completed design against the initial 


design gcals. 


B. REPRESENTING OBJECTS AND VARIABLES 
Let us review the last example written in Omega-1: 


Define froot,"Married",newrel {}}. 
Define f{root,"Brcther", newrel {}}. 
Define í(root,"Bill",newobj(j]. 
Define {root,"Karen",newokj {}}. 
Define {root, "Jce",newobj {}}. 


Define f{root,"Jane",newob j {}}. 


Lefine froot,"SarpleRules", 
<< 
if *Brother(x,Joe) -> Married(x,Karen) ; 
1f *Brother (x,Fill) -> Married (x, Jane); 
>> es 


Act {SampleRules}. 


Bill, Karen, Joe, Jane have been defined as objects in this 
Short program. The variable x represents an unbound vari- 
able. The following code is the same program written in 


Cnega-1.5: 
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"Married" (procedure) is defined as a relation. 
"Brother" (procedure) is defined as.a relation. 
"Bill" (procedure) is defined as an object. 
"Karen" (procedure) is defined as an object. 
"Joe" (procedure) is defined as an object. 


"Jane" (procedure) is defined as an object. 


"Sample rules" (rrocedure) are defined as 
Rules 
If given a person is the brother of Joe 
then the person is married to Karen; 
If given a person is the brother of Bill 
the the person is married to Jane; 


end_rules. 
The sample rules (procedure) are activated. 


Objects and variables may be written in the 1.5 grammar 


as: 
word phrase - ncise preps? noise word? word 


The question mark means optional. A word is simply an iden- 
tifier, as classified by a scanner. The noise word categcry 


includes the indefinite articles a and an and also the defi- 


nite article the. Noise preps is an extensible category 
(Chapter IV) that represents prepositions. Noise rrerrs is 
defined: 

noise preps - ncise prep 


| noise prep noise preps 


Ihe symbcl "|" means or. A noise prep is simply a preposi- 
tion. Notice the optional recursive call in the definition 
of noise preps. This permits the use of multiple word prep- 


cSiticns. Examples cf common prepositions are: 


to 
With 
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TONS 
in addition to 


according to 


Legal instances of the word phrase category in Omega-1.5 


include: 


person 
the person 
with the person 
with George 
to George 
according to George 


acccrding to the person 


Variables and objects can therefore be used as subjects, as 
direct objects, and as indirect objects. With the removal 
of the prepositions and articles, we have a bijective 
Mapping for objects and variables in the Omega-1.5 and 
Omega-1 grammars. Thus, the translation of objects and 


variables is quite simple. 


C. RELATIONS 


1. Name 


HA 


In Omega-1, a relation is named by an identifier 
that becomes globally bound through a definition statement. 
The name is then used in association with asserted tuples of 


that relation as Shown here for the relation contents: 
ccntents (1, x, y) 


In Omega-1.5, an identifier is also defined and glotally 
bound as a name for a relation. The use of the identifier 


is directed, however, by the following rule: 


relation phrase - noise verb not? noise verb? 


word phrase 
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The word phrase category was defined in the previous 
section. Clearly, it has multiple uses. The noise verb 
category represents copulative and auxiliary verbs. One 
noise verb is required, although two are possible. 

One use of the relation phrase category is as a verb 
phrase. This combines an auxiliary verb with a main verb. 
Exanples of auxiliary verbs include is, do, has, and are. 
Ihe main verb would be the defined identifier, as previcusly 
described. Valid examples of the relation phrase category 


might be: 


can write 
should study 
are playing 


Rules can be written in multiple tenses, depending 
upon the proper selection of verb tense and auxiliary verb. 
The present tense can be achieved by using the emphatic word 


do as the auxiliary verb: 
I do study 


The addition of the cptional second noise verb in the rela- 
tion phrase definiticn permits the use of most combinations 
oz the active, passive, and progressive active voices for 
the six Ltasic tenses in English. Table I gives several 
examples. Tenses such aS the future perfect combined with 
the progressive active voices are not permitted as they 


require three auxiliary verbs: 
I will have been calling 


Verb phrases can be easily negated. Recall that in 


Omega-1, a test for an absence of a tuple is written as: 


-ccontents(1,x,y) 


Sm 





| 


TABLE I 
Verb Tense Examples 


| | 
| 
| 
EXAMPLE VOICE TENSE | 
I had called active past perfect 
I was calling progressive past 
active 
I had been called progressive past perfect | 
active 
I will be called passive future | 
I will have called active future perfect 
AA —— —— ee re ee J 








This is accomplished in Omega-1.5 by using the optional word 


not after the first auxiliary verb: 


are not rlaying 
do not study 


have not been called 


Applications of the relation phrase category can 
also be written using copulative verbs. Copulative verbs 
are verbs which connect a subject with its complement. Ihe 
complement is either a predicate noun or a predicate adjec- 
tive. The defined identifier becomes the complement when a 
copulative verb is used. Examples of a copulative verb wita 


a predicate noun as its complement are: 


1s the contents 
is a member 


are the ccmponents 
Examples of predicate adjectives with copulative verts are: 
LS EE 
are happy 
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fert sick 


As with verb phrases using auxiliary verbs, the verb phrases 
with copulative verbs are also easy to use in a check for an 
absence cf a tuple. The optional word not is placed after 
the copulative verb: 


is not the contents 
is not a member 


1ssnot ill 
2. General 


In Omega-1, a relation was viewed as an object name 


combined with a tuple. Sample relations could be: 


push (user,iten, stack) 
contents(list,stack) 


kncw (I,propositicn) 
These relations might be written in Omega-1.5 as: 


A user does push an item on a stack 
A list is the contents of the stack 


I de know the prcposition 


Figure 3.1 shows the mapping between relations in the two 
grammars. 

In Omega-1.5, the first argument to a tuple is 
placed before the relation name. This becomes the subject. 
The predicate consists of the relation phrase and the rest 
of the arguments in the tuple. These remaining arguments 
are essentially indirect and direct objects. The grammar 


specification is: 
sutject relation phrase arguments 


where the subject is an expression and the argurents 


category calis for zero or ncre expressions. If in the 


2 


| RA N 

Pd A 
A list is the contents of the stack 
| 


Note: Noise words are filtered during 
the translation. 


| — —-——M 


Figure 3.1 Mapping Between Relations. 


| contents (list. stack) 
| 

| 

| 

——À 


arguments there is more than one expression, a noise prero- 
sitior must be inserted between each of the expressions. 
Ihe rationale for the preposition requirement is discussed 
in the implementation chapter (Chapter 4). This restriction 


is not a great burden. If a programmer wants to write: 
give(man, dog, tcne) 

in Omega-1.5, he would want to write: 
A man did give a dog a bone. 


The preposition  recuirement wculd necessitate the relation 


to te written as: 
give (man, bone,dcq). 
and translated as: 


A man did give a bone to a dog. 
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DOI LISTS 


Lists have previcusly been described as one of the three 
value components in the system. A sample list expressicn in 


Cnega-1 is: 
(red, white, blue > 
This wculd Le written in Omega-1.5 as: 


the list of red, white, blue 


or the list of rec, white, and blue 


The start of a list is signaled by the term the list. Shans 
again is an extensitle category and will be discussed in 
chapter four. The list maps to the open and closed brackets 


in the Orega-1 syntax (see Figure 3.2). 


(red, white, blue) 
x ` "S 





the list of red, white, and blue 


COMER eS ay ee) Sg net a 


Le 


p 


Figure 3.2 Mapping Between Lists. 





The comma between arguments of a list written in 


Omega-1.S is optional. Consequently, the list 
[nan,implies,nortal] 


could ke written as: 
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the proposition fan implies mortal 


if proposition had teen defined as an extensicn to the 
list starter category. The omission of commas created 
several implementaticn problems, and its use is therefore 


guestionable. 


IE FUNCTIONS 
1. Invocation 


There are two types of function calls in Omega-1.5. 
One type is Similar to the relation format described in 
section C of this chapter. Ihe second type differs in not 
inverting the function name with the first argument. Both 
types are described in the following definition: 


fn_application = word_phrase '(' 'function' ")* 


arguments 


| subject '(' ‘predicate’ *)' 


relation phrase arguments 


Ihe first alternative is the case without the inver- 
Sion cf the first argument with the function name. In the 
original design, this was the only format for a function 


call. Ccmmon Omega-1 functions that fit this category are: 


first| list] 
cons[item,list] 
rest( list ] 


The Omega-1.5 form would be: 


the first (functicn) of a list 


the appending (function) of an item with a list 


the rest (functicn) of a list 
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The notation (functicn) is used to Signal the function call. 
It mafs into the left and right brackets (see Figure 3.3). 
It can be used in a program to reađily spot function calls 
without slowing dcwn their comprehension. Specific words 
were considered to represent the left bracket in lieu cf the 
term (function), but it was felt that a specific word would 
limit the possibilities for expressing function invocaticns 
in a naturalized style. 





cons Citem,listd 


PÁ 


the appending (function) of an item with a list 


M A 





| or) 


fn amr 
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Lugupe 3.3 Mapping Between Functions. 


During the irplementation phase, it became obvious 
Enc navang only one format for function calls was not 
SmETICIGOING. Monster che following built-in functions in 


the McArthur interpreter: 


IsListfiten ] 
IsInt{ iten ] 
IsStr[iten } 


It would be extremely difficult to write these functions in 


Cneja-1.5 without inverting the argument and the function 


EN 


name. Thus the second part of the fn_application definition 
was added. This f£crmat basically applies to any function 
that calls for a true/false or yes/no condition (the func- 
tion does not necessarily have to return a true/false or 
yes/no). The rule: 


If *IsStr[item] -> display {"true'} 
can now te written: 


If given an item (predicate) is a_string 


then "true" (procedure) is displayed 
where a_string maps into IsStr. 
2. Leclaration 


Function declarations in Omega-1.5 are Similar to 
functicn declarations in Omega-1. The only difference is 
that the word function appears in its entirety in tne 
heading instead of being abbreviated as fn. The decisicn to 
keep the same heading was based on the mathematical nature 
usually associated with this applicative component. aA func- 
tion call within a definition, however, (such as a recursive 
call) would be written in the naturalized style. An example 
of a function call in Omega-1 and its translation in 


Cmega-1.5 is presented below: 


Cmega-1: fn numker_items[list]: if list = Wil 
-> 0 


else 1 + number_itemsj rest[iist }}. 


Cmega-1.5: function number itensj list]: 
if list = Nil then 0 
else 1+ the number_items (function) 


in the rest (function) of the list. 


38 


F. PROCEDURES 


Recall that in Cmega-1, procedure calls were alncst 
syntactically identical to the assertion of a relation. The 
only distinguishing item was the use of braces in the rlace 


of the parentheses: 


relation:  contents(5,1list) 


procedure call: pushed {5,stack} 


Procedure calls in Omega-1.5 are also identical to Cmega-1.5 
relations with the exception of one distinguishing element. 
The synbcl (procedure) is used to identify the requirement 
to surround the arguments with braces instead of parentheses 


during translation: 


relation: 5 as the contents of the list 
procedure call: 5 (procedure) is pushed on the 


stack 


Nested procedure calls in Omega-1.5 would appear inside cut 


from a similar structure in Omega-1: 


Cmega-1: a {b {c {d} }} 
Cmega-1.5: d (rrocedure) c (procedure) 


b (procedure) a 


Figure 3.4 shows the mapping  Letween procedure calls in tne 


two grammars. 


G. GENERAL 


Appendix B shows the translation of tne most  ccmmon 
symbols that are nct translated literally from Omega-1.5 


into Cmega-1. The word given is used to replace the cancel- 


lation symbol * in Omega-1. The rule markings, << and >>, 
are respectively represented as Rules and end_rules. 
Sequential control braces are replaced by begin and 
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pushed (5,stack> 





S (procedure) 1s pushed on the stack 
| 





' 
A ne a EE ROT eS na aaa a) 


Figure 3.4 Mapping Between Procedures. 


end_block. This is similar te the block control structures 
begin ard end in ccrventional languages such as Pascal. 
Appendix C lists sample programs which illustrate syntac- 


tical structures in the Omega-1.5 and Omega-1 jrammars. 
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A. GENERAL 


A quick translatcr was developed to test the design 
decisions of the Omega-1.5 grammar. There were two goals in 
the development of the translator. The first gcal was 
Simply tc evaluate the feasibility of the 1.5 grammar. A 
second goal was to explore extensible options to create a 
flexitle environment for the grammar. The implementation 
language was Turbo Pascal [Ref. 18]. Pascal was chosen for 
its simplicity as a high-level language. Turbo Pascal was 
selected as one of the better Pascal environments for proto- 
type programming. The built-in editor and Turbo's speed of 
compilation facilitated the testing and changing of varicus 
design decisions. The inefficiency in the object code and 
the lengthy run-time system that is added during ccmpilation 


were nct considered tc be serious hindrances. 


E. SCANNER AND PARSEE 


The stages of the translator were arranged in a rirpeline 
configuration. The scanner processes input characters to 
recognize tckens. As a token is recognized, it is fed into 
the parser. Token classes consist of identifiers,  delim- 


iters, Strings, and integers. Identifiers are described as: 


(letter) (((letter) | (digit) | _)* 
((letter) | (digit)))* 


where letters can either be upper or lower case. A digit is 
sinply an element of the set (0..9). 
The scanner has two filters. The first screens out 


comments, and the second filters characters that are not in 
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the 1.5 grammar (such as tabs). A carriage return and line 
feed is converted to a space. 
Parsing is done in one pass by recursive descent. This 
required the Omega-1.5 grammar to be massaged into  IL(1) 
form Ey removing left-recursion and nondeterminisn. 


C. TRANSLATION PROCESS 


Translations are performed straight off the parse. 
Brief comments on some of the more intricate aspects of the 
translation process will be presented. Problem areas will 
be higklighted. 

Previcus figures have shown a mapping from several 1.5 
statements into the Cmega-1 syntax. These figures illus- 
trate the switching cf the first argument and the relation 


name. The relation: 

A list is the ccntents of the stack 
comes cut of the pipeline as: 

list ( contents, stack ) 


In this case, contents and list must be switched (see Figure 
4 la). This was relatively easy. 

Figure 4.1b shows a more difficult situation. Here, the 
first argument is a function call. The entire functicn call 
must be switched with the relation name. Additional 
complexity could result with nested calls. The solution was 
to have an output buffer consisting of an array of strings. 
The function call, first[list], was converted during the 
translation into a single string. Thus, the Switch only 
involved two strings. 

Ancther difficulty was inserting commas between argu- 
ments. A comma must be placed after each argument ina 


tuple with two exceptions. One exception is with a unary 


————— — ae  ——Á 
E 
a. 


list (contents,stack) 


b. firstllist) (contents, stack) 


ES A a ao mira Pi nee ema e Me | 


= 


SH gc mmm SE lis AA ar EE ee ter 





Figure 4.1 Switching Relation Name and First Argument. 


tuple. The second exception is after the last argument in a 
nultiple-argument  turle. Commas therefore could not be 
inserted without looking ahead in the translation. 

The open parenthesis of a relation in Onega-1 does not 
have a ccrresponding component in Omega-1.5. In the irple- 
mentation, the auxiliary verb without a (function), (predi- 
cate), or (procedure) in front was used to map into the oten 
parenthesis. This was straightforward. The challenge was 
in closing the open parentheses, brackets, and traces. 
Flags had to be set to insert the proper ciosing after the 


last argument. This is compounded with: 


The appending (function) of the item with the 


list is the contents. 


Here, a closed bracket must be inserted before a closed 


parenthesis: 
contents(consjiten,list]). 


Ncise words (prepcsitions, articles, auxiliary verbs) 


are filtered during translation, as previously discussed. 
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Extensions to the ncise words (section D) are declared 
through a definition statement. These definition statements 
must alsc be filtered. In the implementation, the defini- 
tion was translated into the buffer, with the buffer pcinter 
being reset upon discovering that the definition was for a 
noise word. Thus the definition was deleted before the 
Luffer was dumped to the output file. 

One final implementation problem involved the use of 
prepositions between arguments. Originally, this was not a 
requirement. A problem could result though with the 
following two asserticns: 


A list (procedure) is pcpred off a stack. 


A list (procedure) is pushed on a stack. 
This would be translated as: 


porred (list stack 
pushed {list,stack}. 


If the period after the first statement was accidentally 
omitted, however, the error would be accepted with the 


following translation: 
popred {list,stack, pushed {list,stack}}. 


By inserting the mandatory preposition after the second 
argument, this condition is avoided. Lists that are written 
without the comma option between arguments would still face 


this froklen. 


D. EXTENSIONS 


A key element in Omega-1.5 is the ability to add noise 
words. This feature is essential if flexibility in the 
design is to be achieved. The extensions primarily aprly to 
auxiliary verbs, to prepositions, and to words which signal 
the start of a list. 


gu 


1. Noise Verbs 


Four auxiliary verbs were built into the grammar: 


is, are, has, and do. Suppose, however, that we had the 
relation; 


if *pop(user,stack) -> ... 
and we wanted to translate it as: 
If given a user does pop a stack then ... 


We would need to define the auxiliary verb does. This is 


done Ey: 
"Does" (procedure) is defined as a noise verb. 


The list of noise verbs was implemented as an array of 
strings. The array ceiling was arbitrarily set at twenty. 
The definition statement is not translated--in this case it 
Simply adds the word does to the list of noise verts. When 
an auxiliary verb is expected during the parse, the trars- 


lator does a sequential search through the array. 


2. Nois 


Noise prepositions were handled in the same manner 
as noise verbs. Eleven common prepositions were built into 
the translator (and the grammar). One of the eleven 
built-in prepositions is actually a conjunction rather than 
a preposition, since programming experience showed that the 
conjunction and could add a great deal of clarity in many 
situations that called for an optional preposition. The 
following example shows a suitable case. In this instance, 


and is used to connect two indirect objects: 


Cmega-1: donate(man,money, poor,needy) 
Cmega-1.5: A man did donate money to the poor 


and to the needy 
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Without the use of and, the statement would read: 


The man did donate money to the poor along 


With the needy 


This is guite awkward. 


The large numter of built-in prepositions was origi- 
nally meant to cover the majority of situations in which a 
preposition would be needed. This violates the zero-one- 
infinity principle [Ref. 2], however, and a lesser number 
might ke more effective. Noise prepositions are indicated 
in definitions by the term noise_prep: 


"Off" (procedure) is defined as a noise prep. 


This definition would be required before the fcllecwing 


procedure call wculd be made: 


The top item (prccedure) is popped off the stack. 


3. Noise "List-starters" 


The third area of extensions involves lists. Recall 
that the start of a list was indicated by the default term 
the list. Therefore the list [red,white,blue] could be 
written as: 


the list of red, white, and blue 
In a previous example, a relation was listed as: 


perform (compilers,[ scanning, parsing, 


Code generation]). 


This relation could Ee written as: 


Compilers do perform the operations of scanning, 


parsing, and code generation. 
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Cperations would map into the left bracket, thus signaling 
the start of the list. First, however, operations would 


have tc be appropriately defined: 


"Operations" (prccedure) is defined as a 


list_starter. 


E. ADDITIONAL CONSIDERATIONS 


Two late changes were made to the translator after eval- 
vuating sample test prcgrams. In the initial design, and was 
used instead of a comma to connect multiple inquiries and 
multiple assertions. The translator keyed off the word and 
to determine the end cf the arguments in a tuple. And thus 
had a reserved word status, and could not be used aS a noise 
preposition. This has been shown to be a severe liritaticn. 
Cmega-1.5 was amended to require the use of a comma to 
connect multiple inguiries. The conjunction and was 
inserted into the grammar as an option after the ccnnecting 
comma. If and is present, the translator simply discards 
NL. 

A final change dealt with definition statements. The 
McArthur prototype implemented only one directory nared 
root, which appears as the first argument in a definition 
statement. As the first argument, root would therefore 
Lecome the subject in an Omega-1.5 definition. Programming 
experience demonstrated that the second argument wculd make 
a more logical subject. Conseguently, the one directory is 


cmitted in Omega-1.5 definitions. An Omega-1.5 definition: 
"Contents" (procedure) is defined as a relation. 

is translated as: 
defined {"contents",newrel {}}. 

This would have to be converted to: 
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define {root,"contents",newrel {}}. 


in order to run on the McArthur prototype. À conversion 
rule was then added to the McArthur interpreter. Whenever 
the interpreter is invoked, the following rule becomes 
active: 


definefroot,'"defined",newrel ()). 
define {root,"Defkap", 
<< 
iz *defined(a,n,x) -> define {root,n,x} ,a(n) 
>>}. 
act {DefMap}. 


Rules of the form: 
defined {x, newrel {}}. 

are now automatically converted to: 
define {root,x,newrel (3). 


When multiple directories are implemented, it is envi- 
sioned that the directory name will be used as an adjective 


before the tern relation: 


"Contents" (procedure) is defined as a private 


relation. 


This is easily implemented with the addition of the 


following rule into the previous rule definition: 


lf *defined (a,n,t,x) -> define {t,n,x}, a(n) 
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F. SAMPLE APPLICATICHS 


Five application programs were written to test the 
design and implementation of the Omega-1.5 grammar. The 
Omega-1.5 programs and their Omega-1 translations appear in 
Appendix C. The fcllowing discussion provides a brief 
explanation of each progran. 


FDA iS a prcgran that simulates a deterministic 


pushdown automaton that accepts strings in: 
twow® | win (0 + 1) ¥*} 


A pushdown automaton was selected because it requires a 
stack, and thus would be an excellent exanple for illus- 
trating a stack abstract data type in Omega-1.5. 

Abstract data types are very easy to program in 
Omega. The naturalized format of Omega-1.5 adds a signifi- 
cant degree of clarity and readability to the abstract data 
type rules. In a sense, the rules are almost self- 


documenting code. 
2 Logic) 


Logic5 is a program which demonstrates the use of 
Simple logic in Omega. For example, if the database 


Gommeannis the following concepts; 


Fido is a dog. 
Dog implies aniral. 


Animal implies ncrtal. 


and a query is made as to whether Fido is mortal, the 
program can properly conclude an affirmative response. The 
first example of Logic5 (Appendix C) was written before the 


Omega-1.5 study. It was selected because of its reliance on 
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the use of lists. Lists can be difficult St@uctuwmes to 
translate into a naturalized language. The other twc Lcgic5 
programs in Appendix C are the Omega-1.5 version and the 
resulting Omega-1 translation. The Omega-1.5 version relies 
upon the list starter extension option. This version shows 
the added readability obtained from using the list starter 


extension. 
3. Towers of Hanci 


The Towers cf Hanoi program can be simply solved 


using three rules. This is shown in the first Towers of 
Hanoi example in  Aprendix C. This example was taken fron 
[Ref. 14]. Note tke heavy reliance on recursion. The 


second Towers of Hanci example shows the Omega-1.5 version. 
The Omega-1.5 program introduces greater readability, tut at 
a high cost. It was difficult to verbally describe the 
semantics cf the program. Perhaps the predicate logic style 
night be more advantageous for short programs with extensive 


recursion and numerots applicative components. 


4. ZOO 


The Zoo program was derived from [Ref. 19]. It isa 
prime example for illustrating the use of a naturalized 
style for rule-based systems. The Zoo program is a toy 
analysis system which identifies animals. It involves a 
robot (Robbie) visiting a zoo. Robbie would like to te akle 
to identify the varicus animals. He can see elementary 
features such as size and color, but he cannot combine the 
facts to form conclusions like "this is a zebra." 

To make the reasoning procedure more stimulating, 
intermediate facts are generated. Thus Zoo produces chains 
of conclusions which lead to the identification of a partic- 
ular animal. To limit the number of required rules, we 


suppose that the particular section in which Robbie is 
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visiting contains only seven animals. The rules car be 
understood by examining how Robbie would try to analyze-an 
unknown animal. 

The observed animal has a tawny color and dark 
spots. Rules 9 and 11 are suggested. Neither is triggered, 
however, Since both have additional antecedent conditions to 
be met. Robbie notices that while nursing a baby, the 
animal chews its cud. Evidently the animal gives milk. 
This fact fires rule 2, estaklishing that the animal is a 
mammal. Since the animal is a mammal and the animal chews 
mes cud, rule 8 fires. Thus it is established that the 
animal is an ungulate, and it has two or four toes per foot. 
Next Robbie notices that the animal has long legs and a long 
neck. Rule 11 fires, and the animal has been identified as 
a giraffe. The process is modeled by Figure 4.2. 

Table II shcws a comparison between the rules 
defined in [Ref. 19], the Omega-1.5 version, and the Orega-1 
notation. Note the close similarity between the criginal 
rules and the Omega-1.5 rules. AM Obwarcd—-chainiag, 
deduction-oriented, rule-based system appears to te ideal 


for Omega, especially for the 1.5 syntax. 
5e PIZI 


The final exarpie shows a more serious application. 
It includes the rules and definitions for an interpreter/ 
unparser for a simple language of arithmetic expressions 
composed of +, -, x, /, parentheses, and literal integers. 
Syntax-directed editing rules are also provided. The 
Cmega-1 version was developed by Bruce dacLennan and 
discussed in [Ref. 20]. It was a relatively easy task to 
write the Omega-1.5 version. The added clarity of the 


Onega-1.5 syntax is quite obvious in this example. 
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Figure 4.2 An Example of Porward-Chaining. 


G. | PRCGBAMMING CONSILERATIONS 


Many useful insights were gainei from programming the 
sample application prcgrams. These insights are provided to 
assist future Omega frogramming efforts with the naturalized 
syntax. 

If the relationship name is to be a verb (as opposed to 
a predicate noun or a predicate adjective), use the past 
participle form as much as possible (the past participle 
form of a regular verk is formed by adding ed to the infini- 
tive). This form is guite flexible. All of the tenses in 
the passive voice can be written using an auxiliary vert and 
the past participle. Many tenses for the active voice, such 


aS the present perfect, also use the past participle. Thus 
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TABLE II 


Rule Comparison 


Defined Rules: If the animal is an ungulate 
it has 1cng legs 
it has a lóng neck 
it has a tawny color 
it has dark spots 
then it is a giraffe 


If the animal is a bird 
it does not fl 
lt has lcng legs 
1t has a long neck. 
it 1S black and white 
then it is an ostrich 


Omega-1.5: IE i the animal is an ungulate, 
he animal has long legs, 
the animal has a long neck, 
the animal has a tawny color, and 
the animal has dark, spots 
then the animal is a giraffe 


T£ She the animal is a bird, 
he animal does not fly, 
the animal has long legs, 
the animal has a long neck, and 
the animal is black and white 
then the animal is an Ostrich 


, 


long legs (animal), 


lon3 neck (animal 

tawhy color (animal), 

dark_Spots (animal) 
-> giraffe (animal) 


If *bird (animal), 
~f ly(aniral), 
long_legs(animal), 
long neck (animal), . 
black and white (animal) 
-> ostrich(animal) 


Omega-1: If jong Legs {ani gal 





E ma Dc a O a ipi q ai O o a ij o | mi e ia Fe i al SEC KE RS (gees HI A ma, remem (IPI yeoman, 


i 
| 


the past participle can be used to show action in the rast, 


present, and future: 


If the item has not been pushed then the item will 
be pushed. 


(passive present perfect) (passive future) 
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In some instances, the defined relation name is of a 
form that is just not suitable for that particular instance. 
An ideal solution would be to have an alternate synonym that 
is reccgnized as the same relation. This is possible in 
Cnega. For example, in the Logic5 program, the relation ask 
was defined in its present part, as the relation was going 
to te predominantly used in the future tense. Several 
antecedent conditions required the present perfect tense, 
however, and thus the past participle was needed instead of 
the present part. The solution was to establish the 
following dđefinition: 


"Asked" (procedure) is defined for ask. 


Conseguently, both asked and ask could be used to identify 
the same relation. 

Although the syncnym definition is possible, it should 
te used cnly when ctker options are not feasible. Excessive 
synonyms clutter the program with extra definitions. 

Since Omega-1.5 does not make a distinction between 
upper ard lower case words, be careful to distinguish 
between relation names and unbound variable names. FOL 
instance in Omega-1, Top could be a relation, and top could 
te a variable. In Omega-1.5, the variable top would have to 
ke written in a different form, such as top item. 

A final comment on Omega-1.5 programming is that an 
extensitle noise word should be (as much as possible) the 
same part of speech as the category for which it is teing 
defined. For example, the word questionable could be 


defined as a noise_verb. A rule could then be written: 
If this is questionable programming then ... 
and translated as: 


rrogramming (this) -> aa- 
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This practice was found to add needless definitions to 


programs with little gain in semantic power. 


H. DIFFERENCES FROM THE OMEGA-1 FOUNDATION 


The sample applications have demonstrated four differ- 
ences Letween the Omega-1.5 grammar and the Omega-1 form as 
implemented in the McArthur interpreter. One difference was 
mentioned in the previous section. The Omega-1.5 inplemen- 
tation does not recognize the distinction between upper and 


lower case in nating structures. Thus, 


item 
Ttem 
ittm 
IteM 


will all be recognized as the same object. This ccnvention 
was adopted since an cbject may appear as the first argument 
in an asserted relaticn and should therefore be caritalized 
as the first word in the sentence. Elsewhere, the lower 
case form would most likely be preferred. 

Comments were handled differently in the Omega-1.5 
implementation. Like Omega-1, Omega-1.5 Signals the start 
of a ccmment by an exclamation point. Omneja-1.5 differs 
though in that it alsc requires an exclamation point tc end 
the comment. This permits in-line comments. It proved to 
be quite useful for such functions as numbering the rules in 
the Zoo example and adding clarity to the following rule in 


the FI-1 example: 


If "abort" is the command, and 
given an expression is being evaluated 
tiene do nothing! . 
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In the Omega-1 implementation, statements cculd be 
terminated with either a period or a semicolon. § The semi- 
colon form means parse but don't evaluate. In the Orega-1.5 
grammar, all statements must end with a period except for 
rules within a rule definition. As in Omega-1, rules within 
a rule definition must end with a semicolon. This conven- 
tion was adopted to maintain a sentence-like appearance for 
assertions and definitions. 

One final difference between the two implementations is 
that Omega-1.5 does not permit the establishment of a null 
tuple in a procedure cr a relation. A subject is mandatory 
for each phrase. This limitation did not arise in the exam- 
ples. The only two null tuple procedure calls that were 
found in Omega-1 were the newrel{} and newobj{}. These were 
built into Omega-1.5 simply as relation and object where 
relation maps to newrel{} and object maps to newobjí(]. 
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At the beginning of the second chapter, it was 
stated that one of the goals of the Omega-1.5 grammar was to 
fulfill the intent of the Omega-2 template aprroach 
eed. 15). The sample application programs have provided 
valuatle experience which can be used to compare the 
Omega-1.5 grammar with a template format. 

One key feature of Omega-1.5 is the flexibility that 
is achieved without adding numerous definition statements. 
Fast, present, and future actions can easily be written. 
For example, in the PI-1 program, the following rule was 


used to translate the eval relation: 


If given an expression is being evaluated, 
then noel must be evaluated, and 


node2 must be evaluated; 


This could not be dcne with the template approach without 
adding a new template synonym each time a different tense is 
desired. Also with Cmega-1.5 (as with Omega-1), the rela- 
tion can be defined without first having to determine the 
context in which it will be used. This is not true for 
templates. 

Another advantage of the Omega-1.5 design is the 
ability to handle tuples of various lengths in a relation. 
This feature makes prccedure calls ia Omega-1.5 (adding the 
mailbcx) quite simple. The template approach would require 


a new template for each instance of a relation in which the 
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number of arguments did not agree with the original 
đefiniticn. 

The negation of an inguiry or an assertion is also 
very easy in Omega-1.5. The word not is simply placed after 
the required auxiliary verb or copulative verb: 


are not playing 


is not a member 


Negation in the template approach is formed by placing the 
word not after the first word of the template. This would 
Le unsatisfactory for the following tuples from [Ref. 20: p. 
9e 


— POPS _ 
_ pushes _ on 


_ receives _ 


One last strength of the Omega-1.5 grammar is that 
the Omeya-1 translation is quite readable for individuals 
familiar with the predicate logic style. This is due to the 
direct mapping between Omega-1.5 and Omega-1. Relations in 
the template approach either would have to be transiated 
into Omega-1 by assigning a number (R1 for example) rather 
than a name with semantic connotations, or by some other 
regular mechanism such as concatenating the template's 


rartss 


template: _ pushes _ on 


transiation: pushes on (X,Y,Z) 


Lengthy templates may result in awkward relation names under 
the latter method. 

Templates do have their advantages. Omega-1.5 is 
very weak when adjectives are desired. For instance, in the 


Zoo example, the follcwing relations were defined: 


lcng neck 
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tawny color 


dark spots 


The adjectives Could not stand alone. A template approach 


could easily resolve this: 


. has long neck 
. has tawny colcr 
_ has dark spots 


Templates are also very useful for adding units to numbers 
in a tuple. This weakness in Omega-1.5 is discussed in the 
next section. A final shortccming of the Omega-1.5 grammar 
is that Cmega-1.5 indirectly requires knowledge of the pred- 
icate logic syntax in order to program effectively. This 
Knowledge would not re needed with the template approach. 
Perhaps a ccmbined approach night provide an ideal 
solution for the pseudo-natural notation. Features cf the 
template approach ard the  Omega-1.5 approach could be 
synthesized into a common framework. This would he an 


excellent topic for further research. 
2. Modifications and Extensi 


The programming and irpiementation experience with 
Omega-1.5 has suggested several design modifications tc the 
grammar. Tnese conditions will be addressed as reccmmended 


areas for additional study. 
d. Modifications 


In OMega—-1.5, a variable is bound if it is 
defined in the directcry structure. If èt is not defined, 
it om ccrsadered free. The distinction is made when the 
rules are activated. This requires the programmer to 
remember which names have been previously defined. IEA SO 


requires the programmer to remember reserved words. ns 


could be avoided if there was a syntactical distinction 
between free and bound variables. In the McArthur irnrplenen- 
tation, it was suggested that free variables begin with 
lower case letters, and bound variables begin with upper 
case letters. This is not practical in Omega-1.5. Other 
conventions must be explored. An extra character could be 
added at the end of a free variable for example (list versus 
lista), but this would diminish the readability of the code. 

The use of values is a second area which needs 
to be reexamined. Specific emphasis should be on the use of 
numbers. In many cases, the units of the numbers are 


desired for added readability. For instance, the relation: 
dimensions (rectangle,3,2). 

would te written in Omega-1.5 as: 
The rectangle has dimensions of 3 by 2. 

It would be desirable to be able to write: 
The rectangle has dimensions of 3 feet by 2 feet. 


Omega-1.5 does not permit this, however. The best it can do 


is: 
The rectangle has dimensions of 3 !feet! by 
2 !feet!. 
In this example, the units are described by in-line 
comments. 
A third observation involves the mailkox 
construct. By convention, the mailbox relation for Omega-1 


procedure calls is placed as the first argument in the rela- 
tion's tuple. For example, the procedure pushed is written 


in the premise as: 
pushed (a,x,S) 
and in the conclusion as: 
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pushed (ms) 
In Omega-1.5, pushed would be: 


premise: a user has pushed an item on the stack 
conclusion: an item (procedure) is pushed on the 


stack 


Although this is easily accomplished, it would te even 
Simpler in many cases if the mailbox was placed as the 
rightmost argument in the relation tuple. Therefore pushed 


could ke written as: 


premise: an itez is pushed on the stack by a user 
conclusion: an item (procedure) is pushed on the 


stack 


Here, the basic structure does not change. The only ncdifi- 
cation is the appending of a prepositional phrase to the 


premise side. 
b. Extensions 


There are two extensions to the Omega-1.5 
grammar that should be examined in future studies. 
Currently, only one argument (the subject) is permitted in 
front oí the auxiliary verb and the relation name. while 
translating a previously written interpreter/pretty printer, 


the fcllcwing relaticn was encountered: 
Eval (Template,ncde) 

It would be nice to te able to translate this as: 
The template for the node is evaluated 


This would call for two arguments in front of the auxiliary 


verb and relation name, however. Permitting multiple 
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arguments in front of the relation name would not be a very 
difficult change to implement. It would only require a more 
sophisticated mechanism for inverting the numerous arguments 
with the relation name. 

Just as multiple arguments should be permitted 
in front of the auxiliary verb and relation name, no argu- 
ments should also be permitted. This would allow procedure 
calls (and relations) with null tuples. A procedure call 
could therefore be: 


Do terminate (prccedure). 
This would be translated as: 
terrinatef[). 


Again, this change would be easy to implement without 


causing major parsing problems. 


B. REMARKS ON THE OMEGA CONCEPT 


The Omega language offers an ideal framework for many 
problems. The key ccrponent in Omega is its production rule 
model, Omega favors problems that can be decomposed into 
cause/effect producticn rules. The production rules should 
te independent with minimal communication required between 
the rules. 

The independence between the rules is very important. 
Rules must also be written so that they don't delete infor- 
maticn that may be required by another rule. This prcblem 
was experienced during the development of several rule-kased 
systems. Consider the following example in Omega-1 (Mary, 


John, food, and wine are defined objects): 


define (root, "rules", 
<< if *likes(Mary,x), likes(John,x) -» 
display {"red"} ; 
if *likes(John,Mary), likes (Mary, wine) -> 
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displayf"blue") 
>> 


act {rules}. 
If the user enters the following in the command mode: 


likes (Mary, wine). 
likes (John, wine). 
likes (John, Mary). 


only rule 1 will fire when in fact the user has entered 
proper information tc fire both rules. The problem is that 
one inquiry in the premise must be deleted in order to 
prevent the rule from continuously firing. There are 
programming methods to preclude this condition from occur- 
ring, but they are nct trivial. Perhaps a mechanism can be 
developed so that (if desired) an active rule would fire 
cnly cnce in the same state. 

One other recommended extension is a query capability 
Similar to the question in Prolog. Currently in the command 
mode, a user can find out if John is the brother of Macy by 


entering: 
if brother(John,Mary) -> display{"yes"}. 
It would be nice if the user could instead enter: 


?brother (John,Mary) 


or ?brother (John,x) 


Tt should not be a difficult change to make. The challenge 
would Ee to develcpa suitable representation for the 
Omega-1. grammar. A quick solution would be to terminate 


the statement with a question mark instead of a period: 


John is the brother of Mary? 
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In this case, Omega would respond with either a yes or a no. 


The second example (?rrother(John,x)) could be written: 


John is the brother of whcm? 


where whom represents the uninstantiated variable x. Here, 


Omega would either respond with a binding for x or with Nil. 


C. CCNCLUSIONS 


Ihe Omega system is an object-oriented progranming 
language predicated upon a simulation paradigm. Omega 
differs from conventional languages in that it lacks such 
common structures as variables, assignment statements, and 
most control structures. Rey to the Omega design is the 
event-oriented transaction rule. This is used to describe 
state changes in the systen. 

This thesis has described a stylized natural language 
grammar for the Omega programming language. This grammar is 
offered as an alternative to the predicate logic notation of 
Omega-1. The major advantages of the naturalized style 
include easier reading and semantic understanding of the 
code. 

Principal objectives in the design of the Omega-1.5 
grammar were simplicity and flexibility. The Simplicity of 
the design is evidenced by Omega-1.5's ability to be parsed 
by traditional syntactic parsing technigues. There is no 
need for the conceptual dependency parsing usually associ- 
ated with more sophisticated grammars that attempt to 
ciosely parallel true natural language. Additionaliy, 
Cmega-1.5 avoids the semantic ambiguities that wculd be 
incurred if a true natural language grammar could be 
implemented. 

A prototype translator was built to test the feasibility 


oí the Omega-1.5 design. A major goal in the translator was 
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to examine extensible options for the grammar. 
Extensibility is essential for flexibility in coding 
applications. 

Our final area of emphasis was the development of sample 
applicaticn programs. These programs were developed to 
demonstrate the Omega-1.5 grammar and to suggest potential 
application areas for the Omega language. Possible applica- 
tions range from rule-based systems to programming environ- 
ments. It is hoped that the programming style of these 
programs will assist future Omega programming efforts and 
also serve as a focal point for additional research with the 


Cnega language. 
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APPENDIX A 
SYNTAX OF OMEGA-1.5 


( "2" denotes optional ) 


sessicn = p 


| Statement list '.' 


statement list = statement 


| statement '.' statement list 


statement = cpd rule 


| fn definition 


cpd rule = rule 


l rule 'else'! cpd rule 


rule = start clause cause 'then' effect 
| start clause cause 'then' 
| 'then' effect 


| effect 
start_clause = tat 

| "when! 
cause = conditions 
conditions = conditicn 

| constraint 


| condition *,* *and*'? conditions 


l constraint *',' 'and'? conditions 


condition - 'given'? inquiry 

inquiry - subject relation phrase arguments 
constraint = expression 

effect = transactions 
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transactions 


transaction 


predication 


in_definition 
fn_head 


arglist 


arguments 


arguments! 


list 


seq_block 


s list 


subject 


expressicn 


transaction 
transactions. ,* *'and'? 


transactions 


predication 
expression 


seq block 


subject relation phrase 


arguments 
"Iunmetron' fn head ':' cpd expr 
word phrase? '[' arguments? 'j* 


expression 


expressicn noise preps arglist 
/* empty */ 

arglist 

expression ':' expression 

/* empty */ 

List 

expression ':' expression 


expression 


expression ','? list 
'begin' s list *'end block' 


Statement 


Statement ';' s list 


expressicn 


expression ':' expression 


word phrase 
relation phrase 


constant 
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list_starter 


fn application 


cail 


noise_verb 
noise_word 


noise prep 


noise preps 


word phrase 


rule derotation 


call 

fn_application 

rule_denotation 

unop 

binop 

noise preps? noise word? * (° 
cpd expr ')' 

noise preps? noise word? 
list starter list 

noise preps? noise word? 
list starter expressicn 
':* expression 

noise preps? noise word? 


list starter 
'the_list' 


word phrase '(*' 'function' 
!'*)' arguments 
subject '(' 'predicate' ')' 


relation phrase arguments 


subject '(' 'procedure' ')' 


relation phrase arguments 


'is' | *are'q"maste tao 
ta? | tan? | tthe? 

“of” | “tow ‘tor ptas 
tat?! | uith ralon on 
'from' | "plus ana" 


noise_prep 


noise_prep noise_preps 
noise_preps? noise_word? word 


'rules' s list ';'? 'end_rules' 
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unop 


binop 


relation phrase 


word 


constant 


Cpd expr 


cond expr 


"+' expression 
t-t! expression 


'a' expression 


expression 
expression 
expression 
expression 
expression 
expression 
expression 
expression 
expression 
expression 
expression 
expression 


expression 


noise verb 


IDENTIFIER 


STR_CON 
INT_CON 
NIL 


cond_expr 


'*' expression 
'-* expression 
txt expression 
'/! expression 
'%* expression 
t=! expression 
'<' expression 
">! expression 
'a-! expression 
DE =" 
15 = 


'£' expression 


expression 
expression 
'|'* expression 


'not'? noise verb? 


word phrase 


cond expr 'else' cpd_expr 


expression 


Start clause constraint 'then' 
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expression 


APPENDIX B 
CCMPARISON OF CMEGA-1.5 AND OMEGA-1 CONSTRUCTS 


Le General: 


Omega-1.5 Omega- 1 
then => 
given * 
function fn 
rules << 
end_rules >> 
begin ( 
end block ] 
function [ 
predicate [ 
procedure { 
not > 


EIS Puilt-in Procedures: 


Omega-1.5 Omega- 1 
activate act 
displayed display 
displayed with return displayn 
relation newrel () 
object newobj3 () 


III. Built-in Functicns: 


Omega-1.5 Omega-1 


an_integer IsInt 
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a_string IsStr 


a list IsList 
an object IsObj 
a relaticn IsRel 
converted to string int str 
appending cons 
bound to object objval 
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APPENDIX C 
CCMPARATIVE APPLICATIONS:  OMEGA-1.5, OMEGA-1 


VAR Ke KK eK A A k k k kk k k k k k k kkk kk kK 


* * 
$ PDA -- Omega-1.5 * 
* * 


X c eoe ok oc oo odo oe oo De oe oe eo eoe XGA KK KK aK KKK KI 


Y 
PDA is a program tc implement 
a deterministic pushdown autcmaton (J) 
where J = (fstatel,<tate2),(0,1,c), (red, blue, green), 
o,statel,red,empty stack). 


J accepts {wcw RI win (0 + 1) *} by empty stack. 


This program was developed to show the implementation 


of a stack abstract data type 


! Rules to implement stack abstract data type |! 


"Pushed" (procedure) is defined as a relation. 
"Popped" (procedure) is defined as a relation. 
"Contents" (procedure) is defined as a relation. 
"Available" (procedure) is defined as a relation. 
"Requested" (procedure) is defined as a relation. 
"Destroy" (procedure) is defined as a relation. 
"Top iter" (procedure) is defined as a relation. 


"Cleared" (procedure) is defined as a relation. 


"Does" (procedure) is defined as a noise verb. 
"Sent" (procedure) is defined as a noise_verb. 
"Being" (procedure) is defined as a noise_verb. 


"Want" (procedure) is defined as a noise verb. 
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"New Stack" (procedure) is defined as an object. 
! Put an object in the available relation ! 

An object is available. 

! The stack rules  ! 


Stack rules (procedure) are defined as 
Rules 

If given a user has pushed an item on a stack, and 
given a list is the contents of the stack 

then 
the stack is sent to the user, and 
the appending (function) of the item with the list 

is the contents of the stack; 


If given a user has popped a stack, and 
Nil is the contents of the stack 

then 
Nil is sent to the user, and 


"Stack underflcw." (procedure) is displaved 


Else if given a user has popped a stack, and 
given a list is the contents of the stack 
then 
the first (function) of the list is sent to 
the user, and 
the rest (function) of the list is the contents 
of the stack; | 


If given a user dces want the top item of the 
Stack, and 
a list is the contents of the stack 

then the first (function) of the list is sent to 


the user; 
If given a user has requested a new stack, and 
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given a stack is available 

“then 
the stack is sent to the user, and 
Nil is the contents of the stack 


Else if given a user has requested a new stack 
then 
"No stack available." (procedure) is displayed; 


If given a user dces destroy a stack, and 
given a list is the contents of the stack 
then 
the list is sent to the user; 


If given a user has cleared a stack 
then 
the stack is sent to the user, and 
Nil is the contents of the stack; 


end_rules. 
The stack_rules (procedure) are activated. 


! Request a stack called pda stack ! 
"PDA stack" (procedure) is defined as a new stack 


(procedure) being requested. 


' Rules for the PDA ! 
"Input" (procedure) is defined as a relation. 
"State1" (procedure) is defined as a relation. 


"State2" (procedure) As) defaned sased rem aco. 


"Current state" (procedure) is defined as an object. 
"Red" (procedure) is defined as an object. 

"Green" (procedure) is defined as an object. 

"Blue" (procedure) is defined as an object. 


"C" (rrocedure) is defined as an object. 


1! Initial state ! 


Red (procedure) is pushed on the pda stack. 
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The current_state is statel. 


"PDA rules" (procedure) are defined as 
Rules 
If given a list is input, 
the list 7= Nil, 
the current_state is statel, and 
the first (function) of the list = 0 
then 
blue (procedure) is pushed on the pda_stack, and 
the rest (function) of the list is the input 


Else if given a list is input, 
the list += Nil, 
the current_state is statel, and 
the first (function) of the list = 1 
then 
green (procedure) is pushed on the pda_stack, and 


the rest (function) of the list 1s the input 


Else if given a list is input, 

the list += Nil, 

the current state is statel, and 

the first (function) of the list = c 
then 

the current state is not statel, 

the current state is state2, and 


the rest (function) of the list is the input 


Else if given a list is input, 

the list += Nil, 

the current state is state2, 

the first (function) of the list = 0, and 

the pda stack (procedure) has a top item = blue 
then 

the pda stack (procedure) is popped, and 


the rest (function) of the list is the input 
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Else if given a list is inpuk) 

the list == Nil, 

the current state is state2, 

the first (function) of the list = 1, and 

the pda stack (procedure) has a top item = green 
then 

the pda stack (procedure) is popped, and 

the rest (function) of the list is the input 


Else if given a list is input, 
the list = Nil, 
given the current state is state2, and 
the pda stack (procedure) has a top item = red 
then 
the pda stack (procedure) is popped, 
"accept" (procedure) is displayed, 
1 return Comin. traced oe 
red (procedure) is pushed on the pda_stack, and 
the current state is statel 


Else if given a list is input, and 
given the current state is state2 

then 
"Nc" (procedure) is displayed, 

! return to initial state ! 

the pda stack (procedure) is cleared, 
red (procedure) is pushed on the pda stack, and 
the current state is statel 


Else if given a list is input 
then 
"No" (procedure) is displayed, 
! return to initial state ! 
the pda stack (procedure) is cleared, and 


red (procedure) is pushed on the pda stack; 
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end_rules. 


The pda_rules (procedure) are activated. 


VR KR ee ee ee a eK KK KK X 


: 
T 


T 


E 
PDA -- Crega-1 * 
E 


Y x ok ok ceo COE OCA Dc Doo OOo DER DC oO A A A eee ox x 


! Rules to implement stack abstract data type 


define 
define 
define 
define 
define 
define 
define 
define 


define 


! Put 


{root,"pushed",newrel {3}. 
{root,"popped",newrel {3}. 
froot,"contents",newrel {}}. 
(root,"availaLle",newrelí]]. 
(root,"requested'",newrelí]]. 
(root,"destroy",newrelí]]. 
{root,"top_item",newrel {}}. 
{root,"cleared",newrel {}}. 


froot,"new_stack",newobj {}}.- 


an object in the availatle relation. 


available (newobj{}). 


! The stack rules 


Hcunhelncot,"5tack rules", 


<< 


if *pushed (user, iter,stack), *contents(list,stack) -» 


user (stack), 


Ccontents(cons[item,list],stack); 


if *porped (user, stack), contents(Nil,stack) -» 


user (Nil), 
display {"Stack underflow."} 
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else if *fpopped (user, Stack) 7) #contents (list, stack) => 


user(first[list]), 
contents (rest[ list ],stack) ; 


if *top_ item(user, stack), contents (list,stack) -> 


user(first[list]); 


if *requested(user,new stack), *available(stack) -» 


user(stack), 
contents (Nil,stack) 


else if *requested (user,new stack) -> 


display ("No stack available."); 


if *destroy (user, stack), *contents (list, stack) -> 


user (list); 


if *cleared(user,stack) -» 
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user (stack), 


contents(Nil,stack); 


act (Stack rules). 


! Establish a stack called pda stack. 


define(root,"pda stack",requestedí(new stack]]. 


! Rules for the PDA 


define 
define 
define 
define 
define 
define 
define 


define 


(root,"input",newrel(j]. 
[root,"state1",newrel (3). 
{root,"state2",newrel {}}. 
{root,"current_state",newrel {}}. 
{root,"red",newobj {}}. 
{root,"green",newobj {}}. 
(root,"blue",newobj(3). 


{root "cn newer. 


! Initial state 


pushed {red, pda_stack}. 
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statel(current state). 


define {root,"pda_rules", 


<< 


1£ *input(x), x7=Nil, statel (current state), 


else 


else 


else 


else 


else 


if 


1E 


iE 


first(x]-0 -»5 
pushed (blue, pda stack), 
input (rest[ x }) 


*input (x), x-=Nil, statel(current_state), 
first{x]=1 -> 
pusted (green,pda stack), 
imcut(rest[ x }) 


*input (x), x7=Nil, statel(current state), 
PESAS => 
astatel (current state), 
state2 (current state), 
input (rest[ x7) 


*input(x), Xx2-Nil, state2 (current state), 
first{x]}=0, 
top_item{pda_stack}=blue -> 
porredípda stack), 
input (rcest[ x 2) 


*input (x), xn=Nil, state2 (current state), 
firstj x J=1, 
top item{pda_stack}=green -> 
porred {pda_stack}, 


input (rest[ x’) 


*input (x), x=Nil, *state2(current state), 
top itemípda stackj-red -» 
porredfpda stack], 
display ("accept"), 

! return to initial state 


pushed íred,pda, stack], 


is 


statel (current state) 


else if *input (x), *state2 (current state) -> 
display ("no"), 
! return to initial state 
cleared {pda_stack}, 
pushedí(red,pda stack], 
sStatel(current state) 


else if *input(x) -> 
display ("no"), 
! return to initial state 
cleared fpda stack), 
pushed {red, pda_stack} 
2M 


act (pda rules). 


T ck e a a e e oc e eK KK KK KK 


! * 
! Logic5 —-- Omega-1 E 
! * 


Y OE A A A A A O A AA 


ts 


Logic in Omega 


! Frorositions represented ty values (lists) 


oem 


Ccncepts (objects of knowledge, namely 


! individuals, 'is's and 'imp's) 

! can be represented by either values 

! or objects. 

! They are represented by values (strings) in 

! this example. 

! Eroposition identification by pattern matching. 


' Cognitive functions 
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define {root,"Asks", newrel {}};3 
define {root,"Knows",newrel {}}; 


define (root,"Inquire",newrel (3); 


! Kinds of propositicns 
define (root,"isa","isa"); 
define {root,"imp", “imp"} ; 


define {roct, "not", "nct"} ; 


define {root,"Logic5Rules", 

<< 

! Inquiry management 

if *Inquire(s,p), Knows(s,p) -> displayn ("yes"); 

if *Inquire(s,p), Knows(s, [not,p] -»^ displayní"no'"); 


if Inquire(s,p), -Knows(s,p), -Knows(s, [not,o]), 
“Asks(s,p), -Asks (s, [not,p?) 
-» Asks(s,p), Asks(s, [not,p]); 


if Knows(S,p), *Inguire(s,p) -> displayn ("yes"); 


if Knows(s,[not,q]), *Inguire(s,q) -> displayn{"no"} ; 


! Deductive rules 
if *Asks (s,[isa,X,p]), Knows (s,[imp,q,p]), 
Knows (S,[isa,x,q]) 


-» Kncws (s,[ isa,x,p]) ; 


if Asks(s,[isa,x,p]), Knows(s,[imp,q,p]), 
aKnewsis,TIrisa,x,q]), vAsks(s,[1isa,xX,9)) 

-> Asks (s,[1Sa,xX,q }) 

>>}. 


! Concepts 

define {roct, "man", "man"}; 
define [rO0rt; dog", "dcg"}; 
define (root,"animal","animal"j; 
define  froor)"nortalvW '"mortal"); 


dE root “Soc”; "ecc: 
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define {root, "Fido" ado ae 


! Knowledge 

Knows (self,[ isa, Soc,man)); 

Knows (self ,[ imp,man, animal )) ; 
Knows (self,[imp,animal,mortal]); 
Knows (self,[ inp,dog,animal]); 


KNows (self ,[ isa, Fidc,dog)). 


act {Logic5Rules}. 


Y ok AA A A RR A e ae ee ee Re ee oe ee ee eK eo e Ok k 


* * 
* Logic5 -- Cpega-1.5 * 
* * 


AA AA A A k A AA A ae eK eee ee Ke ee KK eK kK À 


^ 


Propositions are represented by values (lists). 
Concepts are represented by objects in this examrle. 


Propcsition identification by pattern matching. 
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! Ccgnitive functicns : 
"Ask" (procedure) is defined as a relation. 
"Know" (procedure) is defined as a relation. 


"Inquiring" (procedure) is defined as a relation. 
"Asked" (procedure) is defined for ask. 


! Kinds of propositions ! 
"Is_a" (procedure) is defined as an object. 
"Implies" (procedure) is defined as an object. 


"Negation" (procedure) is defined as an object. 
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"TI" (procedure) is defined as an object. 
"Am" (procedure) is defined as a noise verb. 
"Will" (rrocedure) is defined as a noise, verb. 
"Have" (procedure) is defined as a noise verb. 
"About" (procedure) is defined as a noise prep. 
"Proposition tnat!" (procedure) is defined as 

a list_starter. 


"Asserticn" (procedure) is defined as a list starter. 


"Logic ruies" (procedure) are defined as 
Rules 
! Inquiry management ! 
If given I am inquiring about a proposition, and 
I do know the proposition 
then 
"yes" (procedure) is displayed; 


If given I am inquiring about a proposition, and 
I do know the assertion of the negation of the 
proposition 

then 


"nc" (procedure) is displayed; 


If I am inquiring about a proposition, 
do not know the proposition, 
do not know the assertion of the negation 
of the proposition, 

I have not asked about the proposition, and 
have not asked about the assertion of the 
negation of the proposition 

then 
I will ask about the proposition, and 
I will ask about the assertion of the 


negation of the proposition; 


If I do know about a proposition, and 
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given I am inquiring about the proposition 
then | 


"yes" (procedure) is displayed; 


If I do know about the assertion of the 
negation of a proposition, and 
given I am inguiring about the proposition 
then 


"nc" (procedure) is displayed; 


6 en 


Deductive rules : 
Tf given I have asked about the proposition that 
object! is a object2, 
I do know the proposition that 
object3 implies object2, and 
I dco know the proposition that object? is_a 
object3 
then 
I do know the proposition that object! is a 


object2; 


If I have asked aktout the proposition that 
object1 is_a object2, 
I do know the proposition_that object3 implies 
object2, 
I do not know the proposition that object! is a 
object3, and 
I have not asked about the proposition that 
object! is a object3 
then 
I will ask about the proposition that objecti 
is a object: 


end rules. 


I Ccncepts : 
"Man" (procedure) is defined as an object. 


"Dog" (procedure) is defined as an object. 
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"Animal" (procedure) is defined as an object. 
"Mortal" (procedure) is defined as an object. 
"Soc" (procedure) is defined as an object. 
"Fido" (procedure) is defined as an object. 


! Knowledge ! 

do know the proposition that Soc is a man. 

do know the proposition that man implies aninal. 

do kncw the proposition_that animal implies mortal. 
do know the proposition_that dog implies animal. 


Fi WH HH HW Fe 


do know the proposition_that Fido is_a dog. 


The lcgic rules (procedure) are activated. 


T kkk kkk k a e oo oe ook oe ze ooo DOO OOo oo oc Oeo e k k k k k ok 


! * 
! Logic5 -- Omega-1 translated Ei 
! * 


Y c ok ok oo oe ok oco o coe oo oco oc ook ceo o o o oc oe oo oe eo eee ox x 


! Ccgnitive functicns 
defined {"ask",newrel {}}. 
defined {"know", newrel {}}. 


defined {"inguiring",newrel {}}. 
defined {"asked",ask}. 


! Kinds of propositions 
defined ("is_a",newot3(3). 
defined {"implies",newobj {3}. 


defined {"negation", newobj {}}. 
defined {"I",newobj{}}. 


defined {"logic_rules", 
SS 
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! Inquiry management 

if *inquiring(I,propcsition), know(I,proposition) -» 
display{"yes"} ; 

if *inguiring (I,proposition) , 


know (I,[ negaticn, proposition]}) -> display ("no"); 


if inguiring(I, proposition), -~know(I,proposition), 
aknow (I,[ negaticn, proposition ]}), 
nasked(I, proposition), 
asked (I,[negaticn,proposition ]) 


-» ask(I,proposition), ask(I,[negation,proposition]); 


if know(I,proposition), *inquiring(I,proposition) 
-» display ("yes"); 

if know (I,[negation,proposition]), 
*inquiring (I,prcposition) 


-> display {"no"}; 


! Deductive rules 

if *asked(I,[object!,is a,object2]), 
know (I,[object3,imnplies,object2]), 
know (I,[oLject1,is a,object3 ]) 

-» kncw (I,[objecti,is a,object 2]); 


if asked (1,[object1,is_a,object2)), 
know (I,[object3,implies,object2]), 
kncw (1,[object1,is_a,object3]), 
asked (1,[object1l,is_a,object3 J) 

-> ask (T.,[object1,is_a,object3 7) 

>>}. 


1 Ccencepts 

defined {"man",newob j {}}. 
defined {"dog", newob j {}}. 
defined {"animal", newcbj {}}. 
defined {"mortal", newcbj {}}. 
defined ["Soc",newobj(0]. 
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defined ("Fido",newot3(3). 


I Knowledge 

know (I,j Soc,is a,man]). 

know (I,[man,implies,animal]). 
know (I,[animal,implies,mortal]). 
know (I,{ dog,implies, arimal]). 
know (I,[ Fido,is a,dog)). 


act (logic rules). 


Y oo a a a a a NA eo de e KK OK G 


: 


! Towers of Hanoi -- Omega-1 


E 


+ 


& 


* 
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! Define the relaticrs 


define {root,"Hanoi",newrel {}}. 
define froot,"HanoiAux",newrel (3). 


! The rules 

define {root,"HanoiRules", 
<< 

if *Hanoi(a,n) -> 


HanoiAux (a, n, "A", "C", "B"); 


if *HancoiAux (a, 1, frcm, to, aux) -> 
{ 
cisplay{"Move disk 1 from peg "} 
display {fron}; 
display {" to peg "} ; 
displayn {to}; 
ae 


} 
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else if *HanoiAux(a, n, from, to, aux) -> 
{ 
Hanoidux{n-1, from, aux, to}; 
display {"Move disk "}; 
display (n); 
display(" frcm peg "Jj; 
display {fron}; 
display{" to reg '3; 
displayn {to}; 
HanoiAux{n-1, aux, to, fron}; 
anam) 


} 
Sie 


act {HanoiRules}. 
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* * 
* Towers of Hanoi -- Omega-1.5 = 
* x 


Re He eK eR e a e e e e a e e a A A AA 


"Input" (procedure) is defined as a relation. 
"Moved" (procedure) is defined as a relation. 
"PegA" (rrocedure) is defined as an object. 
"PeyB" (procedure) is defined as an object. 


"PegC" (procedure) is defined as an object. 


"Must" (procedure) is defined as a noise verb. 
"Be" (procedure) is defined as a noise, verb. 
"Sent" (procedure) is defined as a noise verb. 


"Does" (procedure) is defined as a noise verb. 
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"Hanoi rules" (procedure) are defined as 
Rules 
If given a user dces input n disks 
then n_disks must be moved from pegA to pegC 


with pegB; 


If given a user has moved 1 from the source peg 
to the destination_peg with the auxiliary_peg 
then 
begin 
"Move disk 1 from peg " (procedure) 
is displayed; 
source _ peg (procedure) is displayed; 
" to peg " (frocedure) is displayed; 
destination reg (procedure) is 
displayed with return; 
Nil is sent to the user 
end block 


Else if given a user has moved the nth disk from 
the source peg to the destination peg with the 
auxiliary peg | 

then 
begin 

The nth disk-1 (procedure) must be moved fron 
the source reg to the auxiliary pey with 
the destination peg; 

"Move disk ™ (procedure) is displayed; 

nth disk (prccedure) is displayed; 

" from peg " (procedure) is displayed; 

source peg (rrocedure) is displayed; 

" to peg " (procedure) is displayed; 

destination reg (procedure) is 
displayed with, return; 
Ihe nth disk-1 (procedure) must be moved fron 


the auxiliary peg to the destiration peg 
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with the source peg; 
Nil is sent to the user 
end block; 


end rules. 


Hanoi rules (procedure) are activated. 


We aK ee he eK eK a ie oe ee ae oo i a oe i oo Fe k kk kk k kk k kkk ko ok 


* 


a: Zoo -- Omega-1.5 


3t 


* 


x 


x 


We He a oc o Re oe oe He ee oe ee ak oe eke ee ee ee ie oe eK ok ok xe x 1 


"Hair" (procedure) is defined as a relation. 


"Mammal" (procedure) is defined as a relation. 


"Give" (procedure) is defined as a relation. 


"Feathers" (procedure) is defined as a relation. 


"Bird" (procedure) is defined as a relation. 


"Fly" (procedure) is defined as 
"Lay" (procedure) is defined as 


"Bat" (procedure) is defined as 


a 


a 
a 


relation. 
relation. 


relation. 


"Carnivore" (procedure) is defined as a relation. 


"Pointed teeth" (procedure) is 
"Claws" (procedure) is defined 
"Forward pointing" (procedure) 
"Hoofs" (procedure) is defined 


"Ungulate" (procedure) is defin 


defined as a relation. 


as 
is 
as 
ed 


a relation. 
defined as a relation. 
a relation. 


as a relation. 


"Chew" (procedure) is defined as a relation. 


"Even toed" (procedure) is defined as a relation. 


"Tawny cclor" (procedure) is defined as a relation. 


"Black stripes" (procedure) is defined as a relation. 


"Dark spots" (procedure) is defined as a relation. 


"Long_legs" (procedure) is defined as a relation. 
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"Long neck" (procedure) is defined as a relation. 
"White cclor" (procedure) is defined as a relation. 
"Black and white" (rprccedure) is defined as a relat ron: 
"Swim" (rrocedure) is defined as a relation. 


"Good flyer" (procedure) is defined as a relation. 


"Eggs" (procedure) is defined as an object. 
"Meat" (procedure) is defined as an object. 
"Eyes" (procedure) is defined as an object. 
"Cud" (procedure) is defined as an object. 
"Animal" (procedure) is defined as an object. 


"Milk" (procedure) is defined as an object. 
"Does" (procedure) is defined as a noise_verb. 


"Zoo rules" (procedure) are defined as 
Rules 
111 aif given the animal has hair then the animal 


is a mammal; 


92$ 
N) 
eu 


if given the animal does give milk then the 


animal is a mammal; 


13! if given the animal has feathers then the 


animal is a bird; 


14! if given the animal does fly, and 
the animal does lay eggs 


then the animal is a bird; 


15! if given the animal is a mammal, and 
the animal does eat meat 


then the aniral is a carnivore; 


16! aif given the animal is a mammal, 
the animal has pointed teeth, 
the animal has claws, and 
the animal has forward_pointing eyes 


then the animal iS a carnivore; 
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vet 


"po 


ie 


ie 


if given the animal is a mammal, and 
the animal has hoofs 


then the animal is an ungulate; 


if given the animal is a mammal, and 
the animal does chew cud 
then the aninal is an ungulate, and 


the animal is even_toed; 


if given the animal is a carnivore, 
the animal has a tawny_color, and 
the animal has dark_spots 
then "The animal is a cheetah" (procedure) 


is displayed; 


if given the animal is a carnivore, 
the animal has a tawny_color, and 
the animal has black_stripes 

then "The animal is a tiger" (procedure) 


is displayed; 


if given the animal is an ungulate, 
the animal has long legs, 
the animal has a long neck, 
the animal has a tawny color, and 
the animal has dark spots 
then "The arimal is a giraffe" (procedure) 


is displayed; 


if given the animal is an ungulate, 
the animal has a white color, and 
the animal has black, stripes 

then "The arimal is a zebra" (procedure) 


is displayed; 


if given the animal is a bird, 


the animal does not fly, 
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the animal has long_legs, 
the animal has a long_neck, and 
the animal is black_and_white 
then "The animal 1S an ostrich" (procedure) 
is displayed; 


1141 if given the animal is a bird, 
the animal does not fly, 
the animal does swim, and 
the animal is black,and white 
then "The arimal is a penguin" (procedure) 


is displayed; 


! 15! if given the animal is a bird, and 
the animal is a gcod flyer 
then "The arimai is an albatross" (procedure) 


is displayed; 
end rules. 


The zco rules (procedure) are activated. 


o a a kok ok 
! * 
! Zoo -- Omega-1 translation * 
! * 


AR RR o oe coo oe oe oce oec eoe oe e e e oe e e GG x KG x 


derined @r'hair™, newrel {}}. 
defined ("mammal",newrel ()).- 
defined {"give", newrel {}}. 
defined {"feathers", newrel {}}. 
defined {"bird", newrel {3}. 
defined {"fly",newrel {}}. 


defined {"lay",newrel {}}. 
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defined 
defined 
defined 
defined 
defined 
detoneg 
defined 
defined 
defined 
defined 
defined 
defined 
defined 
defined 
defined 
defined 
defined 


defined 


defined 
defined 
defined 
definec 
defined 


defined 


defined 
«« 
! 1 


("eat",newrel (3). 
{"carnivore",newrel {}}. 
{"pointed_teeth",newrel {}}. 
{"claws",newrel {}}. 

{"forward_ pointing", newrel {}}. 
{"hoofs",newrel {}}. 
{"ungulate", newrel {}}. 
{"chew", newrel {}}. 

("even toed",newrel()). 
("tawny color",newrel {}}. 
{"black_stripes",newrel {}}. 
("dark spots",newrel [)). 
("long legs",newrel(]). 
("long neck", rewrel ()). 
{"white_color",newrel {}}. 
{"black_and_white", newrel {}}. 
{"swin", newrel {}}. 


f"good flyer",newrel 33. 


("eggs",newob7 (3). 
{"reat", newoLk? {}}.- 
{"Neyes", neworj {}}. 
f"cuar newob 7. 
{"animal", newcbj {}}. 
milk", newok 7 {}}.- 


("zoo rules"; 


if *hair (animal) -> mammal (animal); 


12 


if *give(animal,milk) -» mammal (animal); 


D 


if *feathers(animal) -»5 bird(animal); 
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14 
MEE 


ists 


16 


if 


17 


if 


ES 
if 


1-10 
if 


P 
if 


*fly (animal), lay(animal,eggs) -> bird(animal) ; 


*mammal (animal), eat(animal,meat) -> 


carnivore(aninmal); 


*nammal(animal), pointed teeth(animal), 
claws (animal), forward pointing(animal,eves) -» 


carnivore (animal); 


*mamnmal (animal), hoofs (animal) -> 


ungulate (animal); 


*mammal (animal), chew(animal,cud) -> 


ungulate (animal), even toed (animal); 


*carnivore(animal), tawny color (animal), 
dark s<pots (animal) -> 
display("The arimal is a cheetah"); 


*carnivore (animal), tawny_color(aninmal), 
Elack stripes(anidal) -> 


display{"The animal is a tigerm; 


£ *ungulate (animal), long_legs(animal), 


long neck (animal), tawny color (animal), 
dark spots (animal) -> 


display f"The animal is a yiraffe"} ; 


*ungulate (animal), white color (animal), 


black stripes(animal) -» 
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display ("The arimal is a zebra"); 
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if *bird(animal), -fiy(aninal), 
long_legs (animal), long_neck(aninal), 
black and white (animal) -> 
display ("The animal is an ostrich'"); 
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1f *bird (animal), -fly (animal), 
swin (animal), black and white (animal) -> 


display{"The animal is a penguin"); 


de a 
if *bird(animal), good flyer(animal) -» 
display{"The arimal is an albatross"); 
> 


act (zoo rules]. 
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1 * 
! PI-1 -- Crega-1 * 
1 + 
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1 Rules and associated definitions for 
! an arithmetic expression language. 
1 Relations 


! Prcgram Structure Relations 
define {root,"Appl",newrel {} }; 
define {root,"Op",newrzel {}}; 

define {root,"Left", newrel {}}; 


define {root,"Right" ,newrel {}}; 
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define (Loot, "Con", newsreel {} } ; 


define {root,"Litval",newrel {}}; 
! Evaluation Relations 


define (root,"EZval",newrel(í]]; 

define {root,"Check",newrel {}}; 
define {root,"Value" ,newrel {}}; 
define {root,"Meaning",newrel {}}; 
define {root,"Explanation",newrel {} } ; 


! Unparser Relations 


define {root,"Unparse",newrel {}}; 
define {root,"Image",newrel {}}; 


define {root,"Template",newrel {}}; 
! Command Interpreter Relations 


define [root,"Conmand",newrelí)]); 
define {root,"Argument",newrel {}}; 
define {root,"Root", newrel {}}; 
define {root,"Unde£",newrel {}}; 


define {root,"CurrentXode",newrel (3); 


define {root,"EvalPending",newrel 833; 
define {root,"ShowPending", newrel {}}; 
define {root,"CreateArpl",newrel {}}; 

define {root,"CreateRcot",newrel {}} ; 

Cefine {root,"Script",newrel {}}; 


define {root,"PendScript",newrel {}} ; 
une crons 


LATAR X sek 

AN AS A y; 

RM Lx ys 

fn P Prcoduct Xx + y; 


tnaouorrent ty): 
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lif y = 0 => PPerzor a 


else x / y; 


fn IsErrorcode [vw]: 
if “IsList[w] | w = Nil -> Nil 


fn upSum [x,y ys (ox ee 
fn upDif [x,y]: "(" 4 % e moe 
fn upFrod [x,v ]|: "(" + x + au EINE 


fn upCuot [X;y]: " GN + x + "n/m + y + "mj we 
' Built-in Tables 


Meaning (Sum,"+") ; 
Meaning (Dif,"-"); 
Meaning (Product,"x"); 
Meaning (Quotient,"/"); 
Meaning (Id,"lit"); 


Template (upSun,"+") ; 
Template (upDif,"-") ; 
Template (upProd,"x"); 
Template (upQuot,"/") ; 
Template (int str; Ciao: 


Explanation ("incomplete program", ("error",0)); 


e 


Explanation ("divisicn by zero", j"error",1]). 
! the Rules 


define (root,"PIlRules", 
<< 


' Evaluator Rules 
! Constant nodes 


if *Eval(e), Con (e), Iitval(v,e), Meaning (f,"lit") 


-> Value(fl v),e); 


J5 


! Appl nodes 


if *Eval(e), Appl(e), Left(x,e), Right(y,e) 
zx val(x),"Bval cy); 


if *Value(u,x), *Value(v,y), 
Appl(e), Op(n,e), Ieft(x,e), Right(y,e), 
Meaning (f,n) 

-» Check (f[u,v],9); 


! Error Checking 


if *Check(w,e), -IsErrorcode[w? 


-^ Value(w,e); 


if *Check(w,e), IsErrcrcodei ww], 
Explanation(s,w), *CurrentNode (q) 


-> displayn {s}, CurrentNode (e); 
! Unparser 
! Constant Nodes 


if *Unparse(e), Con(e), Litval(v,e), 
Wcarlate(f,"lit") 
-> Image (f[v],e); 


1 Identifier nodes 
! Appl nodes 


if *Unparse(e), Appl(e), Left(x,e), Right (y,e) 


-> Unparse (x), Unparsé(y) ; 


if *Image(u,x), *Imace(v,y), 
Me Op(n,e), Lert (x,¢), Right {y,¢), 
Template (f,n) 


-> Image (f[ u,v], @) ; 
! Command interpreter Rules 
! evaluate Command 
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if *Command ("evaluate"), CurrentNode (E) 
-» Eval(E), EvalPending (E); 


if *Value(V,E), *EvalEending (E) 
-» displayn (V); 


! return Command 


if *Command ("val"), *Argument (V), CurrentNode (E) 
-> Value (V,E); 


’ shew Ccmmand 


if *Ccmmand("show"), CurrentNode (E) 


-» Unparse(E), ShowPending(E); 


if *Image(S,E), *Showrending (E) 
-» displayn {S}; 


' abort Command 

1f Command ("abort"), *Eval(E) -> ; 

if Command ("abort"), *Value(V,E) -> ; 
if Command ("abort"), *Check(V,F) -> ; 


if *Command ("abort") , ~Eval(E),  Value(V,E) 


-> displayn {"aborted"}; 
' Handle incomplete program 


if *Eval(E), Undef{E), *CurrentNode (Q) 
-> displayn("Incomplete"), CurrentNode (E); 


if *Unparse(E), Undef (E) 
-> Image (“<exypr>1 E); 


! Syntax Directed Editing 


! in Ccmmand 
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if *Ccmmand ("in"), *CurrentNode (E), left (X,E) 
-> CurrentNode (X), Ccrmand("show''); 


if *Command("out"), *CurrentNode(X), Left (X,E) 


-> CurrentNode (E), Ccmnmand("show"); 


if *Command ("out"), *CurrentNode(Y), Right (Y,E) 


-> CurrentNode(E), Ccmnmand("show"); 
! next Ccmmand 


if *Command("next"), *CurrentNode(X), Left (X,E), 
Demon (T7 
-» CurrentNode(Y), Ccmmand("shcw"); 


! prev Ccmmand 


if *Ccmmand("prev"), *CurrentNode(Y), Right (Y,E), 
Et E) 
-» CurrentNode (X), Ccmmand("shcw"); 


1 delete command 


if *Ccmmand("delete") , CurrentNode(E), *Con(E), 
*Litval(V,E) 
=> Undef (E), Command ("show"); 


Ends *Ccnnand ("delete"), CurrentNode(E), 
*Appl(E), *Op(N,E), *Left(X,E), 
Right (Y,E) 


=> Undef (E), Command ("show"); 


if *Ccmmand("delete"), CurrentNode(E), Undef (E) 


-> displayn ("already deleted"); 
! $ Command 


if *Ccmmand("#"), *Argument (V), IsInt{V], 
CurrentNode(E), *Undef (E) 
-> Con(E), Litval(V,F), Command("“show") ; 
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if *Command ("#"), *Argument(V), CurrentNode (£) 
~Undef (E) 
-> displayn ("defined node”) ; 


1+, -, X, / Commands 

if *Command (op), memter [op; [Tem —" 7 so 7 el 
*CurrentNode(E), *Undef (E) 

-> CreateAppl(op, E, newobj(), newobj{}); 

if *CreateAppl(op,E,X,Y) 

-> Appl(E), Op(op,E), lLeft(X,E), Fight (Y,E), 
Undef (X), Undef (Y), CurrentNode(X); 


if *Command(op), member op, | Ven Wo t E 
CurrentNode (E), -^Undef (E) 
-> displayn ("defined node"); 


! begin Ccnmand 


if *Command ("begin") , *Current Node (Q) 


-» CreateRoot(newobj 11); 


if *CreateRoot (E) 
-> Root (E), Undef (E), CurrentNode (E): 


' roct Command 


if *Ccmmand ("root"), *CurrentNode(Q), Root (E) 


=> CurrentNode (E), Ccmmand("show"); 
! Test Driver 
if *Scripft (Nil) -> displayn{"Script completed") 


else if *Script(L), (first[L ]="#" | 
firstiLJ="val") 
=> [ dasplay d ErrStOD reste mM 
displayn {first [L}}; 
Ccmmand (first[L], Argument (first[rest[L]]), 
PendScript(rest[rest[L]]) ) 
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else if *Script (L) 
-> { displayn (first {LJ}; 
Ccmmand (first[ 13), PendScript(rest[( L)) 3; 


if *PendScript (L), Ccmmand(Q) -> Script (L) 
>>}. 
1 activate the rules 


act {FI1Rules}. 
CurrentNode (Nil). 
displayn("PI-1 System loaded"). 
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* 
* PE= IP == Cnega-1.5 * 
* * 
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PI-1 
Rules and associated definitions for 


an arithmetic exression language. 


! Relations ! 
1 Prcgram structure relations ! 


"Application" (procedure) is defined as a relation. 
"Operator" (procedure) is defined as a relation. 

"Left argument" (procedure) is defined as a relation. 
"Right argument" (procedure) is defined as a relation. 


"Constant" (procedure) is defined as a relation. 
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"Literal value" (procedure) is defined as a relation. 
! Evaluation relaticns ! 


"Evaluated" (procedure) is defined as a relation. 
"Checked" (procedure) is defined as a relation. 
"Value" (procedure) is defined as a relation. 
"Meaning" (procedure) is defined as a relation. 


"Explanation" (procedure) is defined as a relation. 
! Unparser relations ! 


"Unparsed" (procedure) is defined as a relation. 
"Image" (procedure) is defined as a relation. 


"Template" (procedure) is defined as a relation. 
! Command interpreter relations ! 


"Command" (procedure) is defined as a relation. 
"Argument" (procedure) is defined as a relation. 
"Root node" (procedure) is defined as a relation. 
"Undefined" (procedure) is defined as a relation. 


"Current node" (procedure) is defined as a relation. 


"Pending evaluation" (procedure) is defined as a relaticn. 
"Shown" (procedure) is defined as a relation. 

"New application" (prccedure) is defined as a relation. 
"New root" (procedure) is defined as a relation. 

"Script" (procedure) is defined as a relation. 


"PenLding script" (prccedure) is defined as a relation. 


! Functions ! 
function identity x x 
function sum [x,y]: x * y. 
functicn difference [x,y]: x - y. 
functicn producto xy gg: X v 
function quotient [x,y]: 
if y = 0 then tre_list of the "error_code" and 1 


else x / y. 
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function error_code [4]: 
if W (predicate) is not a_list | W = Nil then Nil 


else the first (function) of W = "error code”. 


moneti on sum tenplate [x;y]: QU + x "+" y + "", 
functicn difference_template [x,y]: 
"(U ox t "—U oy + MY, 
function product template [x,y !: 
"n qu + xX + "x" + y + 8 "o 
function quotient terrlate [x,y]: 


LET p * X 4 "n7 + Y + We 
1 Built-in tables ! 


sume as the meaning of "+", 
Difference is the meaning of "-". 
Froduct is the meaning of "x", 
Quotient is the meaning of "/". 


Identity is the meaning of "lit". 


Sum template is a template for "+". 
Difference template is a template for "-", 
Product template is a template for "x". 
Quotient template is a template for "/". 


String notation is a template for "lit". 


"Incomplete program" is an explanation for the_list 
of error_code and 0. 
"Divisicn Ev zero" is an explanation for the_list of 


eruoEEGOde and 1. 
! Noise words 1 


"Must" (procedure) is defined as a noise verb. 
"Be" (procedure) is defined as a noise verb. 
"Seing" (procedure) is de£ined as a noise verb. 


"Established" (procedure) is defined as a noise ver. 


vos 


"Hill" (procedure) is defined as a noise_verb. 


"Another" (procedure) is defined as a noise verb. 
! The rules ! 


"PIT rules" (procedure) are defined as 


Rules 
1 Evaluator rules  ! 
! Constant nodes ! 


If given an expressicr is being evaluated, 
the expression is a constant, 
a nunber is the literal value of the expression, 
and a lit function is the meaning 
of nr 
then the lit function (function) of V is the value 


of the expression; 
' Application nodes ! 


Tf given an expression is being evaluated, 
the expression iS an application, 
nodel is the left argument of the expression, and 
node2 is the right argument of the expression 
then node1 must be evaluated, and 
node2 must be evaluated; 


If given valuel is the value of node], 
given value2 is the value of node2, 
the expression is an application, 
a string is the operator of the expression, 
nodel is the left argument of tne expression, 
node2 is the right argument of the expression, and 
an operator functicn is the meaning of the string 
then the operator function (function) of value! and 


value2 must be checked for the expression; 


10 € 


SEO Checking ! 


If given an alleged_error is being checked for an 
expression, and 
the alleged error (predicate) is not an error code 
then the alleged errcr is the value of the expression; 


If given an alleged error is being checked for an 
expression, 
the alleged error (predicate) is the error code, 
a string is an exlanation for the alleged error, 
and given any node is the current node 

then the string (procedure) is displayed with return, 


and the expression is the current node; 


Csiingarser ! 


ts 


Constant Nodes ! 


Tf given an expressicr is being unparsed, 
the expression is a constant, 
value1 is the literal value of the expression, and 
a lit function is a template for "lit" 

then the lit function (function) of valuel is the 


image of the expression; 


Identifier nodes ! 
! Application nodes ! 


If given an expressicn is being unparsed, 
the expression is an application, 
nodel is the left argument of the expression, and 
node2 is the right argument of the expression 
then node1 must be unparsed, and 


node2 must be unparsed; 


If given image1 is the image of nodel, 


given image2 is tte image of node2, 
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the expression is an application, 

a string is the operator of the expression, 

nodel is the left argument of the expression, 

node2 is the right argument of the expression, and 

an operator functicn is a template for the string 
then the operator function (function) of image! and 


image2 is the image of the expression; 
! Command interpreter rules ! 
! Evaluate command ! 


If given "evaluate" is the command, and 
an expression is the current node 
then the expression must be evaluated, and 


the expression is rending evaluation; 


If given valuel is tke value of an expression, and 
the expression is rending evaluation 


then valuel (procedure) is displayed with return; 
! Return command ! 


If given "val" is the command, 
given value? is tke argument, and 
an expression is the current_node 


then valuel is the value of the expression; 
! Show command ! 


If given "show" is the command, and 
an expression is the current node 
then the expression must be unparsed, and 


the expression will be shown; 


If given a string is the image of an expression, and 
given the expressicn must be shown 


then the string (procedure) is displayed with return; 
! Abort command ! 
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If "abort" is the command, and 


given an expression is being evaluated 


Ene ntldo nothing! 


Tf "abort" is the command, and 
given a_value is the value of an expression 


then ido nothing! . 


I£ "abort" is the command, and 
given a value is being checked for an expression 


then !do nothing! . 


If given "abort" is the command, 
an expression is nct being evaluated, and 
a_value is not the value of the expression 


then "akcrted" (procedure) is displayed_with_return; 
! Handle incomplete frogran ! 


If given an expression is being evaluated, 
the expression is undefined, and 
given any node is the current node 
then "Incomplete! (prccedure) is displayed witn teturn, 


and the expression is the current node; 


If given an expressicn is being unparsed, and 
the expression is undefined 


then "<expr>" is the image of the expression; 
! Syntax Directed Editing  ! 
! ain Command ! 


If given "in" is the command, 
given an expressicn is the current_node, and 
node! is the left argument of the expression 
then nodel is the current node, and 


"Show" is the comzrand; 
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If given "out" is the command, 

given nodel is the current node, and 

nodel is the left argument cf an expression 
then the expression is the current node, and 


"Show" is the command; 


If given "out" is the command, 

given node2 is the current node, and 

node2 is the right argument of an expression 
then the expression is the current node, and 


"show" is the command; 
! next Command ! 


If given "next" is tke command, 
given node1 is the current node, 
node1 is the left argument cf an expression, and 
node2 is the right argument of the expression 
then node2 is the current node, and 


"Show" is the command; 
! prev Command ! 


If given "prev" is the command, 
given node2 is the current node, 
node2 is the right argument of an expression, and 
nodel is the left argument of the expression 

then node1 is the current node, and 


"Show" is the command; 
! delete Command |! 


If given "delete" is the command, 

an expression is the current node, 

given the expressicn is a constant, and 

given a value is the literal value of the expression 
then the expression is undefined, and 


"Show" is the command; 


If given "delete" is the command, 
an expression is the current_node, 
given the expression iS an application, 
given a string is the operator of the expression, 
given nodel is the left argument of the expression, 
and node2 is the right argument of the expression 
then the expression is undefined, and 


"Show" is the command; 


If given "delete" is the command, 
an expression is the current node, and 
the expression is undefined 

then "already deleted" (procedure) is 


displayed with return; 
! # Ccmmand ! 


If given "#" is the ccmmand, 
given valuel is tke argument, 
valuel (predicate) is an_integer, 
an expression is the current node, and 
given the expressicn is undefined 
then the expression is a constant, 
value! is the literal value of the expression, and 


"Show" is the command; 


If given "f$" is the ccmmand, 
given value! is tre argument, 
an expression is the current node, and 
the expression is not undefined 

then "defined node" (rrocedure) is 


displayed with return; 
| t, —,oX. / Commands ! 


I£ given a string is the command, 


the string is a merber of the list 
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of "gt, Na AA 
given an expression is the current node, and 
given the expressicn is undefined 
then the expression is established as a 
new application with a string and an object and 


ancther object; 


If given an expressicn is a new application with 
a string and node! and node2 

then the expression is an application, 
the string is the cperator of the expression, 
nodel is the left argument of the expression, 
node2 is the right argument of the expression, 
nodel is undefined, 
node2 is undefined, and 


node1 is the currert node; 


If given a string is the command, 
the string is a member of the list 
IA A A ees 
an expression is the current_node, and 
the expression is not undefined 
then "defined node" (procedure) is 


displayeã with return; 
t! begin Command ! 


If given "begin" is the command, and 
given any_node is the current_node 


then an cbject is established as a new root; 


If given an expressicn is a new root 
then the expression is a root node, 
the expression is undefined, and 


the expression is the current node; 


? roct Ccmmand ! 


If given "root" is the command, 
given any_node is the current_node, and 
an expression is the root_node 

then the expression is the current_node, and 
"show" is the command; 


! Test driver i! 


If given Nil is the script 
then "Script completed" (procedure) is 


displayed with return 


Else if given a list is the script, and 
(ehe first (functicn) ot the list = "E" | 
the first (function) of the list = "val") 


then 
begin 
the first (functicn) of the rest (function) 
reco procedure) às displayed; 
the first (functicn) of the list (procedure) is 
displayed_with return; 
the first (functicn) of the list is the command, 
the first (functicn) of the rest (function) of the 
list is the argument, and 
the rest (functicn) of the rest (function) of the 
last is the pending_script 
end blcck 


Else if given a list is the script 
then 
begin 
the first (functicn) of the list (procedure) is 
displayed with return; 
the first (functicn) of the list is the command, 
and the rest (function) of the list is the 


pending script 


end_bicck; 


If given a list is the pending, script, and 
something is not tbe. command 
then the list is the script; 


end rules. 
! activate the rules ! 


The PI! rules (procedure) are activated. 

Nil is the current node. 

"PI-1 System loaded" (procedure) is 
displayed_with_return. 
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